perm filename F77.IN[LET,JMC]1 blob
sn#330270 filedate 1978-01-16 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00365 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00036 00002 ∂28-Sep-77 0016 MRC
C00038 00003 ∂28-Sep-77 0518 RDR via AMET undergrad CS major
C00041 00004 ∂28-Sep-77 0855 FTP:Feigenbaum at SUMEX-AIM (Response to message)
C00042 00005 ∂28-Sep-77 1644 RPG
C00043 00006 ∂29-Sep-77 1823 PAM
C00044 00007 ∂30-Sep-77 0851 DCL
C00046 00008 ∂01-Oct-77 0642 FTP:ELLEN at MIT-MC (V. Ellen Lewis) Discussion paper
C00048 00009 ∂01-Oct-77 0904 100 : REM via AMET LIZ STIERMAN
C00049 00010 ∂01-Oct-77 1034 FTP:ELLEN at MIT-MC (V. Ellen Lewis)
C00050 00011 ∂01-Oct-77 2043 MRC update on modems and front end sources
C00052 00012 ∂02-Oct-77 1429 DPB
C00053 00013 ∂02-Oct-77 2058 DCO
C00054 00014 ∂02-Oct-77 2117 DCO MAIL
C00055 00015 ∂03-Oct-77 0115 FTP:Geoff at SRI-KA (Geoffrey S. Goodfellow) Dialnet Modem selection
C00057 00016 ∂03-Oct-77 0135 MRC
C00058 00017 ∂03-Oct-77 0148 FTP:Geoff at SRI-KA (Geoffrey S. Goodfellow)
C00060 00018 ∂03-Oct-77 0258 LES Dialnet news article
C00061 00019 ∂03-Oct-77 0912 FTP:Taynai at SUMEX-AIM Tenured Faculty Meeting for 10/4
C00062 00020 ∂03-Oct-77 1347 FTP:CERF at USC-ISI Request for help in data transfer protocol
C00065 00021 ∂03-Oct-77 1452 FTP:WINOGRAD at PARC-MAXC (Response to message)
C00066 00022 ∂04-Oct-77 0139 CLT cs206
C00067 00023 ∂04-Oct-77 0158 LES ∂03-Oct-77 1943 JMC Downtime
C00070 00024 ∂04-Oct-77 0247 RDR via AMET cs major & lots dropping independent use
C00074 00025 ∂04-Oct-77 1120 CCG good news
C00075 00026 ∂04-Oct-77 1156 DEK more up-to-date phone number for cerf
C00076 00027 ∂04-Oct-77 2104 MRC Data transmission info
C00079 00028 ∂04-Oct-77 2252 CLT csac
C00081 00029 ∂04-Oct-77 2321 FTP:RDR at MIT-ML (David Roode) MIT-ML system message with DIALNET ramificatons
C00083 00030 ∂05-Oct-77 0946 FTP:MILLS at USC-ISIE Re: Data transmission info
C00087 00031 ∂05-Oct-77 1456 FTP:Feigenbaum at SUMEX-AIM need to talk re ARPA
C00090 00032 ∂06-Oct-77 0225 LES Luckham PI Memo
C00094 00033 ∂06-Oct-77 0232 LES Microprocessor-controlled modems
C00096 00034 ∂07-Oct-77 1212 TOB visitor
C00097 00035 ∂09-Oct-77 1544 DCL
C00099 00036 ∂09-Oct-77 2022 RAE My paper
C00100 00037 ∂09-Oct-77 2129 ME NS
C00101 00038 ∂10-Oct-77 1716 TOB
C00102 00039 ∂11-Oct-77 1414 RPG
C00104 00040 ∂11-Oct-77 1928 LLW via AMET SAIL Proposal for S-1 Project Participation
C00108 00041 ∂13-Oct-77 1155 CR Inventory Info Needed
C00109 00042 ∂13-Oct-77 1326 LES S1 meeting
C00110 00043 ∂13-Oct-77 1609 TOB
C00111 00044 ∂13-Oct-77 1945 LCW Acknowledgements
C00112 00045 ∂14-Oct-77 1000 JMC*
C00113 00046 ∂14-Oct-77 1013 FTP:CARL at MIT-AI (Carl Hewitt)
C00115 00047 ∂14-Oct-77 1538 MRC Host-host protocol
C00116 00048 ∂15-Oct-77 0139 TVR
C00117 00049 ∂15-Oct-77 2017 FTP:MRC at MIT-AI (Mark Crispin)
C00121 00050 ∂17-Oct-77 0846 FTP:CARL at MIT-AI (Carl Hewitt)
C00123 00051 ∂17-Oct-77 0952 TOB hello
C00124 00052 ∂17-Oct-77 1124 TOB From Ira Goldstein re getting together
C00125 00053 ∂17-Oct-77 1218 DCL
C00126 00054 ∂18-Oct-77 0822 FTP:LISKOV at MIT-DMS Stoyan
C00127 00055 ∂18-Oct-77 0859 CR Telephone Message
C00128 00056 ∂18-Oct-77 0930 DPB Theory Qual
C00129 00057 ∂18-Oct-77 0933 FTP:Feigenbaum at SUMEX-AIM Stanford HPP participation in TV broadcast
C00134 00058 ∂18-Oct-77 1415 ZM Theory Qual
C00135 00059 ∂18-Oct-77 1503 TK via AI LISP[F77,JMC]
C00136 00060 ∂18-Oct-77 1719 BPM
C00149 00061 ∂18-Oct-77 1836 TOB copier
C00150 00062 ∂18-Oct-77 1855 DON
C00151 00063 ∂18-Oct-77 1858 HPM OOPS
C00152 00064 ∂20-Oct-77 1204 CR Telephone Message
C00164 00065 ∂20-Oct-77 1644 LES Carlson visit
C00165 00066 ∂20-Oct-77 2054 CDR via AI lisp history
C00166 00067 ∂21-Oct-77 0015 REM via AMET Hellman, one-time pads, public-key-systems
C00168 00068 ∂21-Oct-77 1244 REP Boden's Book
C00169 00069 ∂21-Oct-77 1333 CGN MACLISP MACRO PACKAGE FOR RECORD STRUCTURES
C00171 00070 ∂21-Oct-77 1417 RAK
C00174 00071 ∂21-Oct-77 1451 JMB colloquium
C00175 00072 ∂21-Oct-77 1530 HVA Informal NSF Visit & Tour of A.I. Lab
C00176 00073 ∂23-Oct-77 0000 MRC REM
C00178 00074 ∂23-Oct-77 2152 PAT San Diego
C00179 00075 ∂24-Oct-77 0958 MTK Request for SAIL account
C00180 00076 ∂24-Oct-77 1712 JBR
C00181 00077 ∂24-Oct-77 1727 JMB CS Colloquium
C00182 00078 ∂24-Oct-77 2144 FTP:LISKOV at MIT-DMS Stoyon
C00184 00079 ∂24-Oct-77 2144 FTP:BOBROW at PARC-MAXC THE RUSSIANS ARE COMING TOMORROW MORNING (TUESDAY) AT 9:30
C00185 00080 ∂24-Oct-77 1713 MRC
C00186 00081 ∂25-Oct-77 0954 DPB Committee Assignments October 25, 1977
C00189 00082 ∂25-Oct-77 1040 HVA NSF TOUR OF AI CANCELLED
C00190 00083 ∂25-Oct-77 1714 JBR
C00225 00084 ∂25-Oct-77 2206 MRC multiplexed connections
C00227 00085 ∂25-Oct-77 2310 MRC modems
C00228 00086 ∂26-Oct-77 0015 LES
C00229 00087 ∂26-Oct-77 0406 MRC Host-host protocols
C00230 00088 ∂26-Oct-77 1103 TOB INTERVIEW
C00231 00089 ∂26-Oct-77 1652 FTP:CARL at MIT-AI (Carl Hewitt)
C00241 00090 ∂26-Oct-77 2313 FTP:Feigenbaum at SUMEX-AIM dinner with the Simons
C00243 00091 ∂27-Oct-77 1320 FTP:CARL at MIT-AI (Carl Hewitt)
C00244 00092 ∂27-Oct-77 1437 FTP:Bob Sproull at CMU-10A DialNet comments
C00256 00093 ∂27-Oct-77 2019 RAK
C00258 00094 ∂27-Oct-77 2032 MRC via AMET Sproull's comments
C00261 00095 ∂28-Oct-77 0836 BPM New ARPA Director?
C00262 00096 ∂28-Oct-77 1016 FTP:Feigenbaum at SUMEX-AIM dinner and discussions with Col. Russell
C00263 00097 ∂28-Oct-77 1311 FTP:Feigenbaum at SUMEX-AIM information update
C00264 00098 ∂28-Oct-77 1451 TED
C00265 00099 ∂28-Oct-77 1902 PMF
C00266 00100 ∂29-Oct-77 0104 MRC Maximum packet size
C00267 00101 ∂30-Oct-77 1313 JMB colloquium
C00268 00102 ∂30-Oct-77 1341 JMB colloquium (date confirmation)
C00269 00103 ∂30-Oct-77 1850 MRC DIALnet mail formats
C00273 00104 ∂31-Oct-77 2217 LES PDP-1
C00274 00105 ∂31-Oct-77 2318 MRC
C00280 00106 ∂01-Nov-77 0047 MRC Host-host protocol memo
C00281 00107 ∂01-Nov-77 0706 MRC Jules Gilbert
C00282 00108 ∂01-Nov-77 1131 FTP:Feigenbaum at SUMEX-AIM more on dinner with the Simons thursday
C00284 00109 ∂02-Nov-77 1616 JP MACLSP meta-D directory feature
C00288 00110 ∂02-Nov-77 1645 FTP:Taynai at SUMEX-AIM Course Evaluation
C00293 00111 ∂02-Nov-77 2157 FTP:Feigenbaum at SUMEX-AIM Feigenbaum's electric calendar
C00294 00112 ∂03-Nov-77 0402 LES Dialnet
C00308 00113 ∂03-Nov-77 1057 RLD
C00311 00114 ∂03-Nov-77 1123 PMF
C00312 00115 ∂03-Nov-77 1401 LES
C00315 00116 ∂04-Nov-77 1513 DCL
C00316 00117 ∂05-Nov-77 0101 JMB Future Intel Processors
C00318 00118 ∂06-Nov-77 1503 RPG New features.
C00320 00119 ∂06-Nov-77 1909 FTP:CARL at MIT-AI (Carl Hewitt)
C00322 00120 ∂06-Nov-77 1946 FTP:CARL at MIT-AI (Carl Hewitt)
C00324 00121 ∂07-Nov-77 0822 FTP:Feigenbaum at SUMEX-AIM reminder re russell tonight
C00325 00122 ∂07-Nov-77 1115 DCL
C00326 00123 ∂07-Nov-77 1434 FTP:CARL at MIT-AI (Carl Hewitt)
C00327 00124 ∂07-Nov-77 2319 CLT 206
C00328 00125 ∂08-Nov-77 0741 FTP:LISKOV at MIT-DMS Stoyan
C00329 00126 ∂08-Nov-77 1104 ZM Logic Quals
C00330 00127 ∂08-Nov-77 1142 RWW samefringe
C00331 00128 ∂08-Nov-77 1412 BPM Exalt the auto
C00343 00129 ∂08-Nov-77 1451 FTP:Taynai at SUMEX-AIM Ph.D. oral
C00345 00130 ∂08-Nov-77 1455 RWW samefringe
C00346 00131 ∂08-Nov-77 2206 SGK Economy
C00347 00132 ∂09-Nov-77 1006 FTP:Feigenbaum at SUMEX-AIM visit by Marvin
C00348 00133 ∂10-Nov-77 1238 FTP:MINSKY at MIT-AI (Marvin Minsky)
C00349 00134 ∂11-Nov-77 0047 LES Bureaucracy meeting
C00350 00135 ∂11-Nov-77 1033 FTP:Zenon Pylyshyn at CMU-10A A.I. - philosophy study group @ Stanford
C00352 00136 ∂11-Nov-77 1046 DCO
C00353 00137 ∂11-Nov-77 1719 MRC phone call
C00354 00138 ∂11-Nov-77 2300 DCL bureaucracy
C00357 00139 ∂12-Nov-77 0102 LES LLL visit
C00358 00140 ∂12-Nov-77 0120 LES
C00359 00141 ∂13-Nov-77 0326 JBR
C00362 00142 ∂13-Nov-77 0340 MRC irt JBR's message.
C00363 00143 ∂13-Nov-77 0344 JBR
C00365 00144 ∂14-Nov-77 1534 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Study of electronic mail systems for the FCC
C00368 00145 ∂14-Nov-77 1718 DCL
C00371 00146 ∂14-Nov-77 1736 DCL
C00372 00147 ∂15-Nov-77 0001 LES
C00373 00148 ∂15-Nov-77 0213 LES LLL visit
C00374 00149 ∂15-Nov-77 0253 LES
C00376 00150 ∂15-Nov-77 0638 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
C00377 00151 ∂15-Nov-77 1324 PAT airline reservations
C00381 00152 ∂15-Nov-77 1607 FTP:CARL at MIT-AI (Carl Hewitt)
C00382 00153 ∂16-Nov-77 0756 FTP:JRBII@MIT-ML (Bob Boonstra)
C00385 00154 ∂16-Nov-77 1004 FTP:Zenon Pylyshyn at CMU-10A Phone numbers, comments, etc
C00389 00155 ∂16-Nov-77 1231 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Request to change time of meeting on the 29th
C00390 00156 ∂16-Nov-77 2247 LES LLL visit
C00392 00157 ∂16-Nov-77 2323 DCL bureaucracy
C00394 00158 ∂17-Nov-77 1034 PAT but you said...
C00410 00159 ∂18-Nov-77 0840 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
C00411 00160 ∂18-Nov-77 1426 100 : cr Phone Message
C00412 00161 ∂18-Nov-77 1627 DCO
C00413 00162 ∂19-Nov-77 0914 RDR via AMET long message
C00418 00163 ∂19-Nov-77 2257 MRC
C00420 00164 ∂19-Nov-77 2343 LES Dialnet & Bell Labs
C00423 00165 ∂19-Nov-77 2356 MRC
C00427 00166 ∂19-Nov-77 2358 MRC
C00428 00167 ∂20-Nov-77 1304 DCL
C00429 00168 ∂22-Nov-77 0131 CLT Ch2 Sect6
C00445 00169 ∂23-Nov-77 1259 ZM LOGIG QUALS
C00447 00170 ∂23-Nov-77 1319 ZM LOGIC QUALS - revised schedule
C00448 00171 ∂23-Nov-77 1451 PAT
C00450 00172 ∂24-Nov-77 0026 LES FR group
C00451 00173 ∂25-Nov-77 0004 LES SOB
C00454 00174 ∂25-Nov-77 1214 RWW scott kim
C00455 00175 ∂25-Nov-77 1337 NH Hi. Am around, probably message at lenore morrell
C00456 00176 ∂25-Nov-77 2001 ACH via UTAT ALT
C00457 00177 ∂25-Nov-77 2237 DCO
C00458 00178 ∂26-Nov-77 1816 LES
C00459 00179 ∂28-Nov-77 0000 JMC*
C00466 00180 ∂28-Nov-77 1617 DCL
C00467 00181 ∂28-Nov-77 1717 JBR
C00491 00182 ∂28-Nov-77 2124 REF AI lab seminar
C00493 00183 ∂29-Nov-77 0811 FTP:CARL at MIT-AI (Carl Hewitt)
C00494 00184 ∂29-Nov-77 0852 FTP:CARL at MIT-AI (Carl Hewitt)
C00496 00185 ∂29-Nov-77 2309 TOB Workshop
C00497 00186 ∂30-Nov-77 0312 REM
C00500 00187 ∂30-Nov-77 1234 FTP:Feinler at SRI-KL (Jake Feinler) NIC Questionnaire
C00503 00188 ∂30-Nov-77 2307 LES Student Research Assistantship
C00504 00189 ∂30-Nov-77 2315 RWW memo
C00505 00190 ∂01-Dec-77 0939 100 : cr Phone Message
C00506 00191 ∂01-Dec-77 1000 JMC*
C00507 00192 ∂01-Dec-77 2000 MRC via AMET My move out here
C00509 00193 ∂01-Dec-77 2125 AJT
C00510 00194 ∂02-Dec-77 1300 JMC*
C00511 00195 ∂02-Dec-77 1315 FTP:MINSKY at MIT-AI (Marvin Minsky)
C00513 00196 ∂02-Dec-77 1505 FTP:Sacerdoti at SRI-KL (Earl Sacerdoti) Quasar robot & your letter
C00515 00197 ∂02-Dec-77 1522 FTP:Brian K. Reid <BR10 at CMU-10A> Quasar letter
C00518 00198 ∂02-Dec-77 1559 RPG NCOMPLR
C00519 00199 ∂02-Dec-77 1843 FTP:AMAREL at RUTGERS-10 letter to justice department
C00520 00200 ∂03-Dec-77 1426 LES
C00522 00201 ∂03-Dec-77 1823 RPG Maclisp Manuals
C00524 00202 ∂04-Dec-77 0057 LES
C00525 00203 ∂04-Dec-77 0114 LES
C00526 00204 ∂04-Dec-77 1420 LCW S-1 Architecture Document
C00527 00205 ∂05-Dec-77 0027 MRC DIALnet mail
C00529 00206 ∂05-Dec-77 0115 MRC
C00531 00207 ∂05-Dec-77 0901 FTP:RSMITH at RUTGERS-10 QUASAR
C00543 00208 ∂05-Dec-77 1121 RWW
C00544 00209 ∂05-Dec-77 1107 100 : cg quals etc
C00545 00210 ∂05-Dec-77 1134 RWW
C00546 00211 ∂05-Dec-77 1444 DCL
C00547 00212 ∂05-Dec-77 1621 JMB LOTS
C00549 00213 ∂05-Dec-77 1658 DCL SEMINAR ON RUNCHECK
C00550 00214 ∂05-Dec-77 1907 MFB phone
C00551 00215 ∂05-Dec-77 2300 DPB LOTS
C00561 00216 ∂06-Dec-77 0653 MRC
C00562 00217 ∂06-Dec-77 0841 MRC DIALnet mail
C00563 00218 ∂06-Dec-77 0941 FTP:JZS at CCA Sam Strugglegear assails Boston
C00564 00219 ∂06-Dec-77 1008 CR Phone Message
C00565 00220 ∂06-Dec-77 1050 DPB
C00567 00221 ∂06-Dec-77 1111 FTP:CARL at MIT-AI (Carl Hewitt)
C00576 00222 ∂06-Dec-77 1923 FTP:STEIG at MIT-AI (Richard Steiger)
C00577 00223 ∂06-Dec-77 1947 FTP:HENRY at MIT-AI (Henry Lieberman)
C00578 00224 ∂06-Dec-77 2040 AJT
C00579 00225 ∂06-Dec-77 2335 DCL
C00580 00226 ∂07-Dec-77 1115 JMC*
C00581 00227 ∂07-Dec-77 1409 RAK
C00582 00228 ∂07-Dec-77 1422 FTP:Feigenbaum at SUMEX-AIM Re: REMINDER...REMINDER...REMINDER
C00583 00229 ∂07-Dec-77 1442 FTP:STEFFERUD at USC-ISI Re: Quasar
C00585 00230 ∂07-Dec-77 1543 FTP:STEFFERUD at USC-ISI FYI [JMC at SU-AI (John McCarthy): Quasar]
C00587 00231 ∂07-Dec-77 1546 FTP:STEFFERUD at USC-ISI Content of LA-TYPE-FOLKS: list
C00589 00232 ∂07-Dec-77 1620 FTP:CARL at MIT-AI (Carl Hewitt)
C00592 00233 ∂07-Dec-77 2059 FTP:CARL at MIT-AI (Carl Hewitt)
C00593 00234 ∂07-Dec-77 2138 FTP:STEFFERUD at USC-ISI [Dcrocker at Rand-Unix: Quasar Quack...]
C00595 00235 ∂07-Dec-77 2132 DGR via NBST HSTHST.PRO
C00603 00236 ∂07-Dec-77 2344 MRC irt your message on Pearl Harbor Day, 1977
C00608 00237 ∂08-Dec-77 1415 FTP:PRATT at MIT-AI (Vaughan Pratt)
C00612 00238 ∂08-Dec-77 1446 FTP:Geoff at SRI-KA (Geoffrey S. Goodfellow) VADIC 3467.
C00614 00239 ∂08-Dec-77 1859 JMC*
C00615 00240 ∂09-Dec-77 0115 MRC
C00617 00241 ∂09-Dec-77 0409 MRC Allocations in ACKs
C00619 00242 ∂09-Dec-77 1057 CR Phone Message
C00620 00243 ∂09-Dec-77 1101 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
C00621 00244 ∂09-Dec-77 1213 DPB Spring AI courses
C00624 00245 ∂12-Dec-77 0000 JMC*
C00625 00246 ∂12-Dec-77 0118 MRC US/Mexico prisoner exchange
C00626 00247 ∂12-Dec-77 1100 JMC*
C00627 00248 ∂12-Dec-77 1100 JMC*
C00628 00249 ∂12-Dec-77 1117 FTP:Brian K. Reid <BR10 at CMU-10A> LA robot visit
C00629 00250 ∂12-Dec-77 1138 TOB student
C00630 00251 ∂12-Dec-77 1208 CCG cs229
C00632 00252 ∂12-Dec-77 1315 DPB Spring Class schedules
C00634 00253 ∂12-Dec-77 1348 DCL
C00635 00254 ∂12-Dec-77 1356 DCL
C00636 00255 ∂12-Dec-77 1513 FTP:Hart at SRI-KL (Peter Hart) ( Forwarded Mail )
C00643 00256 ∂12-Dec-77 1517 FTP:MINSKY at MIT-AI (Marvin Minsky)
C00644 00257 ∂12-Dec-77 1516 FTP:MINSKY at MIT-AI (Marvin Minsky) Hart's technology forecast
C00645 00258 ∂12-Dec-77 1616 KJK dialnet
C00646 00259 ∂12-Dec-77 2054 FTP:MINSKY at MIT-AI (Marvin Minsky)
C00648 00260 ∂12-Dec-77 2114 FTP:MINSKY at MIT-AI (Marvin Minsky)
C00649 00261 ∂12-Dec-77 2119 FTP:Brian K. Reid <BR10 at CMU-10A> Re: Justice letter
C00652 00262 ∂12-Dec-77 2139 FTP:MINSKY at MIT-AI (Marvin Minsky)
C00654 00263 ∂12-Dec-77 2144 FTP:Brian K. Reid <BR10 at CMU-10A> anachronistic insert
C00655 00264 ∂12-Dec-77 2152 FTP:MINSKY at MIT-AI (Marvin Minsky)
C00657 00265 ∂12-Dec-77 2158 FTP:Brian K. Reid <BR10 at CMU-10A> Klatu
C00658 00266 ∂12-Dec-77 2333 SMG
C00660 00267 ∂13-Dec-77 0310 100 : REM
C00661 00268 ∂13-Dec-77 0330 LES ERTRIS
C00662 00269 ∂13-Dec-77 0818 FTP:Hart at SRI-KL (Peter Hart) Re-transmission
C00669 00270 ∂13-Dec-77 0948 FTP:Buchanan at SUMEX-AIM (Response to message)
C00670 00271 ∂13-Dec-77 1252 JJK
C00674 00272 ∂13-Dec-77 1532 MRC
C00675 00273 ∂13-Dec-77 1551 FTP:Brian K. Reid <BR10 at CMU-10A> reporters
C00676 00274 ∂13-Dec-77 1842 HPM So sorry
C00678 00275 ∂14-Dec-77 0138 FTP:Su-Ai at SRI-KA (Stanford Ai lab) REM
C00679 00276 ∂14-Dec-77 0921 FTP:Buchanan at SUMEX-AIM (Response to message)
C00680 00277 ∂14-Dec-77 1422 REF Comments on Reiger's CSA and the Marvellous Drinkng Bird:
C00684 00278 ∂14-Dec-77 2019 RCM Sato material and my SRI login
C00685 00279 ∂15-Dec-77 2024 RCM McCarthy-Sato paper
C00686 00280 ∂17-Dec-77 2309 REM via AMET DIALNET, TELENET, ET AL TO BE ILLEGAL MAYBE
C00687 00281 ∂17-Dec-77 2359 MRC Ma Bell s***s long and totally
C00689 00282 ∂18-Dec-77 0023 MRC Christmas party (maybe)
C00691 00283 ∂19-Dec-77 1017 CR Phone Message
C00692 00284 ∂19-Dec-77 1205 RWW
C00693 00285 ∂19-Dec-77 1224 FTP:SUZUKI at PARC-MAXC The decision procedure for quantified S expressions
C00699 00286 ∂19-Dec-77 1305 DCO s-expressions
C00700 00287 ∂19-Dec-77 1333 JJK
C00702 00288 ∂19-Dec-77 1358 FTP:SUZUKI at PARC-MAXC Re: s-expressions
C00704 00289 ∂19-Dec-77 1438 DCO
C00708 00290 ∂19-Dec-77 1447 DCO
C00709 00291 ∂19-Dec-77 1508 FTP:SUZUKI at PARC-MAXC (Response to message)
C00711 00292 ∂19-Dec-77 1514 FTP:SUZUKI at PARC-MAXC (Response to message)
C00713 00293 ∂19-Dec-77 1529 FTP:SUZUKI at PARC-MAXC NP-completenss of the theory
C00714 00294 ∂20-Dec-77 0934 CR Phone Message
C00715 00295 ∂20-Dec-77 1743 REM
C00716 00296 ∂21-Dec-77 0017 FTP:Boyer at SRI-KL (Bob Boyer) The Correctness of a Decision Procedure for Prop. Calculus
C00719 00297 ∂21-Dec-77 1005 FTP:MINSKY at MIT-AI (Marvin Minsky)
C00721 00298 ∂21-Dec-77 1301 FTP:Boyer at SRI-KL (Bob Boyer) A subtle termination argument.
C00725 00299 ∂22-Dec-77 1035 DPB AI colloquium
C00726 00300 ∂25-Dec-77 1336 JP maclsp pty's
C00727 00301 ∂26-Dec-77 0541 REM Data-compressing
C00728 00302 ∂28-Dec-77 1307 REF
C00729 00303 ∂28-Dec-77 2117 DCO
C00731 00304 ∂29-Dec-77 1120 HVA NSF Proposal - Basic Research in Artificial Intelligence
C00732 00305 ∂29-Dec-77 1537 LES KA10 mortgage agreement
C00733 00306 ∂29-Dec-77 1733 FTP:Wiederhold at SUMEX-AIM System curriculum approval
C00736 00307 ∂30-Dec-77 1014 FTP:Wiederhold at SUMEX-AIM Curriculum committee meeting
C00740 00308 ∂30-Dec-77 1201 JJK
C00741 00309 ∂31-Dec-77 1027 FTP:Wiederhold at SUMEX-AIM FYI: meting of curriculum committee
C00743 00310 ∂31-Dec-77 1856 FTP:CARL at MIT-AI (Carl Hewitt) My evaluators
C00755 00311 ∂01-Jan-78 0400 MRC
C00756 00312 ∂01-Jan-78 2239 FTP:CARL at MIT-AI (Carl Hewitt)
C00757 00313 ∂02-Jan-78 1624 MRC
C00758 00314 ∂02-Jan-78 1629 SGK Passport
C00759 00315 ∂02-Jan-78 2324 DPB
C00761 00316 ∂03-Jan-78 0909 TED
C00762 00317 ∂03-Jan-78 1235 FTP:EF at MIT-AI (Edward Fredkin)
C00763 00318 ∂04-Jan-78 0949 TED GUESS WHAT.
C00764 00319 ∂04-Jan-78 1058 FTP:Hart at SRI-KL (Peter Hart) AI Technology Forecast
C00783 00320 ∂04-Jan-78 1500 FTP:Feigenbaum at SUMEX-AIM Re: Forest Baskett
C00784 00321 ∂04-Jan-78 1500 FTP:Feigenbaum at SUMEX-AIM Re: Forest Baskett
C00785 00322 ∂04-Jan-78 1534 FTP:Feigenbaum at SUMEX-AIM recommendation for appointment
C00787 00323 ∂04-Jan-78 1624 MLG
C00788 00324 ∂04-Jan-78 1652 EJM via AMET teasching language
C00789 00325 ∂04-Jan-78 1701 GG thanks
C00790 00326 ∂05-Jan-78 0902 FTP:Taynai at SUMEX-AIM (Response to message)
C00791 00327 ∂05-Jan-78 1954 DCL
C00793 00328 ∂06-Jan-78 0812 BS Faculty Meeting Minutes
C00794 00329 ∂06-Jan-78 1715 JBR
C00819 00330 ∂07-Jan-78 1409 FTP:Cathy Shaw at MIT-ML Quasar expose.
C00821 00331 ∂08-Jan-78 0139 FTP:CARL at MIT-AI (Carl Hewitt) just checking
C00832 00332 ∂08-Jan-78 1602 FTP:PRATT at MIT-AI (Vaughan Pratt)
C00833 00333 ∂09-Jan-78 0949 PAT j,pat and ito
C00834 00334 ∂09-Jan-78 1537 TOB student
C00835 00335 ∂09-Jan-78 2219 TOB terminals
C00836 00336 ∂10-Jan-78 2251 DCL
C00839 00337 ∂11-Jan-78 0913 CJS computer chess
C00840 00338 ∂11-Jan-78 0922 FTP:Levin at SUMEX-AIM forest baskett
C00841 00339 ∂11-Jan-78 1426 BS F. Baskett
C00842 00340 ∂11-Jan-78 1648 LLL next appointments and promotion meeting
C00843 00341 ∂12-Jan-78 0531 HPM New privilege system
C00844 00342 ∂12-Jan-78 1100 JMC*
C00845 00343 ∂12-Jan-78 1435 JMB colloq.txt
C00846 00344 ∂13-Jan-78 0130 PMF
C00847 00345 ∂13-Jan-78 0140 GFF via SRKA HOMEPC.NS[1,GFF] @ SAIL
C00848 00346 ∂13-Jan-78 0752 BS Meeting re Margaret Jacks Hall
C00849 00347 ∂13-Jan-78 1033 DES
C00850 00348 ∂13-Jan-78 1646 FTP:Levin at SUMEX-AIM Senior Faculty meeting
C00851 00349 ∂13-Jan-78 1651 FTP:Lederberg at SUMEX-AIM Re: Senior Faculty meeting
C00852 00350 ∂13-Jan-78 2159 RWW BLIND ROBOT
C00853 00351 ∂14-Jan-78 1143 FTP:Hayes-Roth at Rand-Unix Comments on AI Technology Forecast Outline
C00898 00352 ∂14-Jan-78 1149 FTP:Hayes-Roth at Rand-Unix Comments on AI Technology Forecast Outline
C00943 00353 ∂14-Jan-78 1236 RSC
C00945 00354 ∂14-Jan-78 2105 DCL
C00947 00355 ∂15-Jan-78 1701 SJT via RNDU
C00948 00356 ∂15-Jan-78 2241 JMC
C00949 00357 ∂15-Jan-78 2314 FTP:CARL at MIT-AI (Carl Hewitt) just checking
C00950 00358 ∂15-Jan-78 2340 MRC via WPAT PETITION
C00951 00359 ∂16-Jan-78 0918 PAT
C00952 00360 ∂16-Jan-78 0933 FTP:Levin at SUMEX-AIM letter to Mrs. Forsythe re: contribution to dept.
C00953 00361 ∂16-Jan-78 1156 DCO seminar
C00954 00362 ∂16-Jan-78 1202 FTP:Levin at SUMEX-AIM letter to Mrs. Forsythe
C00956 00363 ∂16-Jan-78 1207 FTP:Levin at SUMEX-AIM letter to Mrs. Forsythe
C00958 00364 ∂16-Jan-78 1220 MRC
C00961 00365 ∂16-Jan-78 1220 MRC via WPAT privileges
C00963 ENDMK
C⊗;
∂28-Sep-77 0016 MRC
To: JMC, LES
∂28-Sep-77 0014 JMC
To: BOB, JMC, sproull at CMU-10A
CC: MRC
Bob,
We have an NSF grant to develop Dialnet - protocols for giving ARPAnet
like facilities to users of telephones. We should have preliminary
protocols in a few months. The initial test machines will be
SAIL and LOTS, a DEC-20 at Stanford for teaching and unsponsored
research. Since it is a standard DEC-20, the programs will be immediately
usable by Caltech if theirs is likewise standard. Various files in
[DIA,JMC] are relevant. The man doing the work is Mark Crispin who is
called MRC here. He has some preliminary documentation in some files.
John
[MRC - Which reminds me--we had better start poking DEC for the front end sources!!]
∂28-Sep-77 0518 RDR via AMET undergrad CS major
Have you heard any repeatable murmurings within the CS department?
Did they realize they got the petition? Is anything
happening? In particular, has anyone, or everyone, said that
Stanford CSD is too research oriented to stoop to those
low level undergrads and dismissed thier interest as "vocational?"
I have heard nothing about the petition. Too many people
are away during the summer, and no department meetings to be held.
The most effective thing would be for some interested students to
meet with the department chairman. I never heard anyone mention
the idea of an undergraduate major would be vocational. On the other
hand the department is very research oriented. The most common
point made is that the department would need more faculty to offer
an undergraduate major, and part of any proposal to the university to offer
such a major would be a request for the necessary faculty positions.
Researchers always welcome new positions, because it allows new fields
to be covered. However, organizing an undergraduate major will be
a lot of work, and I am not volunteering, even though I am convinced
of its desirability. My guess is that if requests for such a major
get to the top of the departmental agenda, and stay there for a while,
the major will happen if the university can be persuaded to allocate
the resources.
∂28-Sep-77 0855 FTP:Feigenbaum at SUMEX-AIM (Response to message)
Date: 28 SEP 1977 0854-PDT
From: Feigenbaum at SUMEX-AIM
Subject: (Response to message)
To: JMC at SU-AI
In response to your message sent 28 Sep 1977 0847-PDT
Please call Carolyn Tajnai 497-4079 or 497-3264
-------
∂28-Sep-77 1644 RPG
To: JMC, JRA
∂28-Sep-77 1634 FTP:RJF at MIT-MC (Richard J. Fateman)
Date: 28 SEP 1977 1933-EDT
From: RJF at MIT-MC (Richard J. Fateman)
To: RPG at MIT-MC
Do you know of anyone working on a maclisp for a 32 bit computer like dec's
unannounced item, or a rival (like hp)? IBM 360 or 370 does not count.
∂29-Sep-77 1823 PAM
John I need to talk to you re my reading committe very soon.
∂30-Sep-77 0851 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR TUESDAY 4th OCTOBER
PLACE: ERL 237
TIME: 2.00 pm.
TITLE: THE NEW SIMPLIFIER
*********************
SPEAKER: DEREK OPPEN
I will describe the internal structure of the simplifier. In
particular, I will discuss what facilities are available to anyone wanting
to add a new special purpose prover to the simplifier.
I would come to the Verification Group seminar if it were at 2:30 rather
than 2. My class ends at 2:30 on Tues. and Thurs.
∂01-Oct-77 0642 FTP:ELLEN at MIT-MC (V. Ellen Lewis) Discussion paper
Date: 1 OCT 1977 0941-EDT
From: ELLEN at MIT-MC (V. Ellen Lewis)
Subject: Discussion paper
To: CLT at SU-AI, JMC at SU-AI
Sorry for my incomplete reference last night (I was rushing to catch a bus
and was afraid I might not get back to my terminal while you people were
still around). The discussion paper to which I am referring is
"Comments on 'The State of Technology in Artificial Intelligence' by Duda,
Nilsson, and Raphael"
which was submitted to Mike Hammer for the book on Software Technology
edited by Wegener, Dennis, Hammer and Teichow.
If a source file for it is still on line, I would appreciate being able
to FTP it. Thanks.
I'll try to find it, but I don't remember now what I called it.
∂01-Oct-77 0904 100 : REM via AMET LIZ STIERMAN
If you still believe tht inviting Liz and me to a party will
significantly improve the chance of her taking a romantic interest in
me, now is our first chance to try the tactic. (At the time of your
original offer she was about to leave for home for summer in Hawaii,
and since has been living at locations unknown.) I found out just last
night that she is currently living at the Bridge, thus can be reached
at (49)7-3392.
∂01-Oct-77 1034 FTP:ELLEN at MIT-MC (V. Ellen Lewis)
Date: 1 OCT 1977 1333-EDT
From: ELLEN at MIT-MC (V. Ellen Lewis)
To: jmc at SU-AI
Thank you very much!
∂01-Oct-77 2043 MRC update on modems and front end sources
To: JMC
CC: LES, REG
Jeff says things are stabilized enough so that the modems can be ordered
whenever we want to. Ralph says he thinks the front end sources are going to be
coming in on a PDP-11 format RP06 pack or something like that so it's going
to be a bit of a bother; as I understand it LOTS will have to be taken
down to read the files and copy to magtape where it can be read by a PDP-10.
Then it can be put on line here and on LOTS.
Problems: (1) what are we going to do about disk space here for those
front end sources? I think it's reasonable for me to want to use E to
edit them. (2) There are a lot of people at LOTS who are itching to go
hack the front end sources. Something is gonna have to be done to get
this coordinated to avoid timing errors in hacking it! McCarthy suggested
that some free volunteer LOTS labor can be exploited for this; but I
would like to see this under control.
Disk space will be made available here and at LOTS.
∂02-Oct-77 1429 DPB
To: JMC
CC: PAM
∂30-Sep-77 1646 JMC Paul Martin
I need a few more days to decide whether I will be a reader of Martin's thesis.
OK. -Denny
∂02-Oct-77 2058 DCO
The problem with 2:30 for the verification seminar is that everyone
always arrives late, they often run an hour and a half and everyone wants a
break before the CS colloquium. However, given the fact that they never start
on time, you can undoubtedly arrive at 2:30 and not have missed a thing!
∂02-Oct-77 2117 DCO MAIL
To: MACLSP.DIS[AID,RPG]:;
Minor update to MAIL in maclsp. (MAIL <destination> <message>)
evaluates <desination> and <message>, and mails the latter to the former.
e.g (mail 'dco x) will send whatever x is to me. (mail <desination>)
will prompt for the message. (mail) will prompt for both <destination>
and <message>.
∂03-Oct-77 0115 FTP:Geoff at SRI-KA (Geoffrey S. Goodfellow) Dialnet Modem selection
Date: 3 Oct 1977 0107-PDT
Sender: GEOFF at SRI-KA
Subject: Dialnet Modem selection
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: JMC at SAIL
Cc: MRC at SAIL
Message-ID: <[SRI-KA] 3-Oct-77 01:07:36.GEOFF>
Have you guys decided upon what type of modem you are going to
use for Dialnet communications? We have bunchs of VADIC's around
here at SRI (in fact I'm sending this message from my home
Datamedia via a VADIC), and they are incredibly reliable, and for
the few glitchs we have had, the factory fix-it place is right
down in mountain view. If you guys do decide to go VADIC, we
should then beable to talk DIALNET to you without much expense I
would guess.
I think the only other 1200/1200 modems around arethe Telco, and
they won't even sell them to you (or so I'v heard). [And also
not to mention they are THE PHONE COMPANY]
I would be interested in hearing what you finally decide on.
[Geoff]
-------
∂03-Oct-77 0135 MRC
To: Geoff at SRI-KA
CC: JMC
I believe that "we" want Vadic modems, and it seems that that is what
McCarthy wants too. There is some talk though that Telco modems are
going to be what "everybody" is going to have and all that and that
we would be screwing ourselves to go Vadic. Except for a gut reaction
not to go Telco, I prefer to be neutral on the matter and let JMC and
LES decide; I'm too much of a coward to want the responsibility (or in
particular the blame) if the "wrong" decision is made.
∂03-Oct-77 0148 FTP:Geoff at SRI-KA (Geoffrey S. Goodfellow)
Date: 3 Oct 1977 0142-PDT
Sender: GEOFF at SRI-KA
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: MRC at SU-AI
Cc: JMC at SU-AI
Message-ID: <[SRI-KA] 3-Oct-77 01:42:52.GEOFF>
In-Reply-To: Your message of October 3, 1977
Actualy, I think it is going to be the other way around. Isn't
that the way it is now? I know of no one on the ARPANET who has
ANY Telco style high speed dial up's, but I am aware of many
places that have VADIC style dial up's. One of the things I have
heard in VADIC's favor though, is that if this so calld
'standard' ever prevails itself, you can just slide out your
modem board from the chassy (very easy to do) and sendit down to
VADIC where either magic will be done to it, or you will be given
a new one which will talk the new standard.
Also you might note, that all TELENET (i.e. commercial ARPANET)
high speed dial up's are of the VADIC flavor, however it seems
that TYMNET chooses to support both flavors at this time.
I hope you end up witn VADIC's, I'm really pleased with them
myself.
-------
∂03-Oct-77 0258 LES Dialnet news article
There is a copy in your mailbox; the source is DIAL.PUB[D,LES].
∂03-Oct-77 0912 FTP:Taynai at SUMEX-AIM Tenured Faculty Meeting for 10/4
Date: 3 OCT 1977 0912-PDT
From: Taynai at SUMEX-AIM
Subject: Tenured Faculty Meeting for 10/4
To: JMC at SAIL, Buchanan, Herriot at SAIL, Floyd at SAIL
Prof. Feigenbaum has canceled the tenured faculty meeting scheduld for
Tuesday, Oct. 4. He said it would be rescheduled at a later time.
Carolyn Tajnai
-------
∂03-Oct-77 1347 FTP:CERF at USC-ISI Request for help in data transfer protocol
Date: 3 OCT 1977 1339-PDT
From: CERF at USC-ISI
Subject: Request for help in data transfer protocol
To: jmc at SU-AI
cc: les at SU-AI, cerf, mills at ISIE
Mail from USC-ISIE rcvd at 3-OCT-77 1254-PDT
Date: 3 Oct 1977 1254-PDT
From: MILLS at USC-ISIE
Subject: Data transmission info request
To: [ISIE]<LOU>SATELLITE.GROUP:
0L-22T-22L22L
People:
I'm sure this problem has come up before: Does anyone have any suggestions
for inputting bulk data (about 30K bytes) from a smart terminal to a net host?
I have in mind the transfer of text from a mini over POT (Plain Old Telephone)
lines through a TIP to a TOPS-20 system, and can easily construct a pair of
cooperating FORTRAN programs, if required. My problem is possible loss of
data due to TIP buffer overruns and the like. A useful solution would be to
extend the net GA (Go-Ahead) message beyond the TIP, perhaps using the same
DC1/DC3 conventions used by TOPS-20.
If anyone knows of a source (man, machine or whatever) which can help,
I would appreciate the advice. If this is (as I suspect) likely to
bring down a rain of abuse on my poor head, I will beat a hasty retreat
to the nearest tape drive!
Regards,
Dave Mills
-------
John,
I thought you or one of your students might be able to respond as a
result of your work on dial-net.
Vint
-------
∂03-Oct-77 1452 FTP:WINOGRAD at PARC-MAXC (Response to message)
Date: 3 OCT 1977 1439-PDT
From: WINOGRAD at PARC-MAXC
Subject: (Response to message)
To: PAM at SU-AI
cc: ccg at SAIL, jmc at SAIL
In response to your message sent 3 Oct 1977 1043-PDT
Wed is OK with me, except there is a small chance
I will be making a last-minute out of town trip
Wed. or Thurs. i won't know fur sure until tomorrow.
If I'm here any time is OK
-------
∂04-Oct-77 0139 CLT cs206
Maclisp at LOTS seems to work as before. Manuals and Notes are in the bookstore
in the CS text section.
∂04-Oct-77 0158 LES ∂03-Oct-77 1943 JMC Downtime
To: JMC
CC: JC
To: LES, JC
It is not legitimate to schedule downtime for any purpose but system
improvements or debugging. The time made available for that purpose
is not to be used for any other purpose. In 1966 it was settled that
this is a time-shared machine and only uses compatible with this are
allowed.
Downtime
While the Soviet Union may get away with revising history periodically,
you can't. In fact, your statement in 1966 was precisely the opposite of
what you now claim: that bare machine time would be scheduled for whatever
processes require it. While it was used fairly often in the early days,
ways were subsequently found to avoid it in most cases. Bare machine
time was also often provided to Feigenbaum's crew as a point of personal
privilege, even though they didn't need it.
In the current situation, JC was having trouble with a realtime operation
(audio tape writing) because of variable disk throughput under load.
This was the final step in an important project that he had been working
on for some time. He inquired about using bare machine and I agreed,
provided that busy periods were avoided.
Hopefully, the new disk system will soon be tuned to the point where this
problem does not recur.
Now, if you would like to change the policy, feel free. But don't try
to pretend you have been consistent for the last ten years.
∂04-Oct-77 0247 RDR via AMET cs major & lots dropping independent use
1) Carolyn Taynai has said that students are requested to
talk to the visiting committee about an undergraduate major.
I contacted Ed Frank and then independently before I replied to
her so did she. He will at least come. Others are
being informed -- I see new people who are interested all
the time. Someone on the committe likes the idea or there would
be no invitation. TThanks for telling Feigenbaum as
otherwise not informing the undergrads of the meeting or informing
them late might have put a damper on the whole thing.
2) I don't know what to do about the advisory board. I am not the
person to espouse the points in the message I sent you and Ralph
at LOTS. Interesting point: all LOTs users are totally convinced
that the independent access is irrevocable. There has been nothing
public from anyone to suggest otherwise (except what I told
some people the CSD wanted from your meeting which I basically
snooped out of you and Ralph). Letting sleeping dogs lie might be
appropriate at this point, as the improvement in system response time
has been a factor of 10 (computed by taking ratio of user
percentage over load average [percent available
to running process] now to what it was before) and the
throughput at peak times has been increased by a factor of
4. Since there are still 128K and a 3rd disk channel (not paid
for) to come, things might be Ok even with 30 more terminals too.
Several times with all terminals in use, there has been idle time over
a period of half an hour. (The crunchers have been staying off
for some reason--it started this past week before the new
system was put up.)
I think that the calculations I suggested publicizing are worthwhile
and I would hope that you and Ralph would put them forth. Ralph
DOESN't do things that prepare for distant future eventualities though.
∂04-Oct-77 1120 CCG good news
To: JMC, LES
At last, NSF said yes. A staggering 24k grant. At least it's a foot in the
door for more AI research.
Cordell
∂04-Oct-77 1156 DEK more up-to-date phone number for cerf
202-694-3049
∂04-Oct-77 2104 MRC Data transmission info
To: Mills at USC-ISIE, Cerf at USC-ISI
CC: LES, JMC
It depends upon how soon you want this; if you want DIALnet you certainly
will win using it, but you will have to wait a while. Conversely you can
talk to Erik Gilbert about his PTF program which is what we are using as
a temporary stopgap until DIALnet is brought up. The problem is that PTF
while reliable (ie, you are guaranteed a good copy since it checksums and
all that) is very slow, kludgy, and written in SAIL (a local form of ALGOL).
You are probably best off using magtape for the nonce; it implies some
inconvenience but it is certainly safer if you are in a hurry. If magtape
is unacceptable, I would suggest a simple set of Fortran programs. The
first sends n ASCII characters and then a checksum (truncated to 7 bits)
and then waits for an ACK or an NAK (you decide what to do about this).
If it receives an NAK it repeats it. Each bunch of characters should have
a sequence number (an ASCII character) which changes with each group and
if it doesn't get an ACK or a NAK it sends the "packet" again with the same
number. The receiver should compute the checksum and send ACK if it matches
it's computed one or NAK if it doesn't.
Both ends should time out in n seconds. If the sender doesn't get an NAK
or ACK, it sends the packet again (if the receiver gets a duplicate packet
it acknowledges it and ignores it). If the receiver does not get a packet
or does not appear to get all of it in the timeout time it sends a NAK
to say are you there.
This should work for you. It is very crude. I would suggest character
packets of 100 characters or so at most, and timeout quanta of 5 seconds
or something. Don't be surprised if it is horribly slow. But it should
work. Good luck (you'll need it!!!!!!!). -- Mark
∂04-Oct-77 2252 CLT csac
I am helping gather data for a report to be given to the CS advisory committee.
In particular we need to obtain the following data about each faculty member:
(1) Research: particular results obtained or projects carried out last year,
and current projects. (Not the generalities such as go into the CS research
report.) (2) A list of phd advisees and there thesis topics if known. I have
extracted an approximation to (2) from the department files and put it in a
file called csac.jmc[1,clt]. Perhaps you could check this for accuracy
and add a few lines covering (1) to the file. (Or point me to a file from
which I can extract the data.) Preferably in the next few days. Thanks.
∂04-Oct-77 2321 FTP:RDR at MIT-ML (David Roode) MIT-ML system message with DIALNET ramificatons
Date: 5 OCT 1977 0222-EDT
From: RDR at MIT-ML (David Roode)
Subject: MIT-ML system message with DIALNET ramificatons
To: JMC at SU-AI
DISTRIB: *MULTICS, *AI, *DM, *MC, *ML
EXPIRES: 10/17/77 00:00:00
POSTER@DM 10/03/77 10:59:34 Re:
Research Assistant - Center for Policy Alternatives
RESEARCH ASSISTANT WANTED
Electronic Message Services: Prospects and Policies
Immediate opening for a graduate research assistant to work on
a survey for the Federal Communications commission of Electronic
Message Services (e.g. Telex, Computer Mail, Communicating Word
Processors). Project entails literature review, evaluation of
market forecasts and interviews with electronic message system
designers, vendors and users.
Emphasis on market prospects and regulatory policy questions
which such systems pose for the FCC.
Contact Dr. Marvin Sirbu x1660 E40-250
Center for Policy Alternatives - MIT
∂05-Oct-77 0946 FTP:MILLS at USC-ISIE Re: Data transmission info
Date: 5 Oct 1977 0945-PDT
From: MILLS at USC-ISIE
Subject: Re: Data transmission info
To: MRC at SU-AI, Cerf at USC-ISI
cc: LES at SU-AI, JMC at SU-AI, MILLS
In response to the message sent 4 Oct 1977 2104-PDT from MRC at SU-AI (Mark Crispin)
Mark,
Thanks for your helpful suggestions. I've just had a long talk
with Joel Malman at BBN. Apparently it is not possible to find out the
length of the TIP buffer for a particular line unless you first
identify the TIP port number and then call him (Joel) to find
out the assembly parameter defining the length for that particular
port. He is sending me via netmail the parameters that apply to the
TIP's I use, but this seems an awkward operation.
Unfortunately, the data I have are on floppy disk in AAED double-density
format, which is not readable on standard drives. (The reason I have
it in that format is that I can put more than 12 times the standard
128-K maximum on the media (both sides), but it has the effect of
isolating me from the usual DEC peripherals. It is possible for me
to transcribe the data on a more suitable medium with some effort,
either Magtape or standard floppy disc. However, I would like to be
able to transmit data from my machine in real time, as changes and
updates to the source will have to be maintained in duplicate on
both the LSI-11 and TOPS-20 systems.
The folk at UCL (London) are working on an X.25 interface for the SATNET
gateways. If all goes according to plan (mine) I will have an
interface on my machine that is compatable with it. That opens interesting
avenues for data transmission. Unfortunately, the coopeerating system
at my end is the one I want to transmit to the TOPS-20 host!
As observed, eggs don't chickens lay.
As an avid Amateur radio fanatic with considerable radioteletype
gear, I can think of more exotic ways to transmit the stuff. It would
only take about 30 hours that way at 45.45 baud in the Baudot code!
Thanks again for your suggestions. I'll let you know how it works out.
Regards,
Dave
-------
∂05-Oct-77 1456 FTP:Feigenbaum at SUMEX-AIM need to talk re ARPA
Date: 5 OCT 1977 1456-PDT
From: Feigenbaum at SUMEX-AIM
Subject: need to talk re ARPA
To: jmc at SU-AI
John, I will be seeing Dave Russell next Tuesday. Before that I need to
talk with you because he is going to ask me things I need your advice
and guidance on, to wit:
1. he wants to know if we have made any progress toward the merger of
the two AI contracts (AI and HPP) that he asked us for last March when
we visited ARPA. (Since we have more than 2 years to accomplish this, I
dont know why he is asking now, but he did). Anyway, it's reasonable
that you and I should begin to do some planning.
2. He wants ideas for exciting innovative computer science projects
for IPTO to be sonsoring in the years to come (say the next five years).
His feeling is that IPTO is currently eating its intellectual capital,
and needs to generate some new ideas, technology, etc. to sustain
the momentum for the future. Here's your chance to generate another
"landmark memo" (ala your famous timewharing memo).
Will you be around the house on Sunday? Do you want to talk then? We
could do it at your house or mine. Or we could get together on Friday
on campus will be better for me if you will be on campus that day).
Or we could do it on Monday. What's your pleasure?
Ed
-------
Sunday will be good for me, since Vera will be away. Call when ready.
∂06-Oct-77 0225 LES Luckham PI Memo
Here is a draft of the memo requesting PI status for DCL.
I can't print it because the XGP is down.
Massage it as you like.
∂AIM 5 October 1977$Gerald Lieberman, Acting Vice Provost for Research
$John McCarthy, Director, Artificial Intelligence Lab
$Proposed Exception to PI Policy for David Luckham∞
.begin ref;
[1] J. McCarthy and D. Luckham, "Verification Oriented Programming",
proposal to National Science Foundation, June 1975.
.end
Two years ago a proposal was submitted to N.S.F. with David Luckham
and I listed as Co-principal Investigators [1, enclosed].
This proposal was accepted and funded under Grant MCS 76-00327, which
runs out shortly.
The work has been progressing satisfactorily under Dr. Luckham's
direction and it appears appropriate to seek follow-on funding.
Since this is really Luckham's research program and since he and his
students are making excellent progress, I believe that he should be the Principal
Investigator on the renewal. Since his position is currently Senior Research
Associate, I understand that special approval is needed to do this.
This work benefits the Computer Science Ph.D. program in providing both
research topics and student support. Several excellent dissertations
have been written by his recent students (e.g. Buchanan, Suzuki, and Cartwright).
It is unlikely that this project will continue unless David Luckham is
designated as Principal Investigator. While I am interested in having
this work continue in our laboratory, my personal research interests now
lie in different directions and I am seeking separate N.S.F. funding.
Luckham is very well qualified to continue this program. He initiated
the last proposal [1] and would like to continue. The follow-on proposal,
if approved, will cover a two year period.
The project could be terminated gracefully at the end of that time
if that seems appropriate then.
In order for this work to continue without a funding gap, it is necessary
for the proposal to reach N.S.F. by November 1.
If you concur with this undertaking, we will submit the proposal
through the usual approval channel immediately.
.skip 2
cc: Edward Feigenbaum, Halsey Royden
∂06-Oct-77 0232 LES Microprocessor-controlled modems
By the way, according to the report "All About Modems" that you (or someone)
left on my desk awhile back, there are some high speed modems with built-in
microprocessors, to make them adaptive to line conditions.
I passed the report to MRC, so you can get it if you are interested.
Little point in passing stuff about modems to MRC; he has a determined
lack of interest in helping decide what to do about them. What interested
me was not a microprocessor controlled modem, but a modem that did
its signal conversion in a microprocessor. Some people say that's the
way to go, and others say that microprocessors are too slow to do
the conversion at the higher transmission rates.
∂07-Oct-77 1212 TOB visitor
John
McCluskey received a letter from Theo Pavlidis,
of the faculty at Princeton Univ. Pavlidis wanted
to come here for 3-6 months, with his salary paid
either by Princeton or by a fellowship. McCluskey
thought that we would be best for this. He sent it
on to me. I would like to have him and propose to
call him. The deadline for the fellowship had passed
before McCluskey returned to find the letter, but I
would like to go ahead and talk with him.
Tom
Sure. Do it.
∂09-Oct-77 1544 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR TUESDAY 11th OCTOBER
PLACE: ERL 237
TIME: 2.00 pm.
TITLE: THE STRUCTURE OF AUTOMATED PROOFS OF COMPILER CORRECTNESS
*********************************************************
SPEAKER: WOLF POLAK
Wolf has been designing and implementing a compiler for a fairly useful
subset of Pascal. He has some ideas about "structuring" the compiler
and specifying the correctness of each part. This should enable proofs
of compiler correctness to be obtained with the verifier, where
"correctness" has a precise definition and the compiler actually works!
∂09-Oct-77 2022 RAE My paper
I'm very appreciative of the fact that you took the time to read my paper and
I would be very interested in hearing your reactions. Unless you want to
meet at some prearranged time (I'm free most any time), I will try and drop by
when you have some free time.
∂09-Oct-77 2129 ME NS
∂09-Oct-77 1850 JMC
NS gives ill mem ref with keyword CARTER (among others).
[ME - Now fixed. There was a clobbered data file.]
∂10-Oct-77 1716 TOB
To: TED, JMC, LES, PAT
There will be a party for the hand/eye group and robotics class
at my house, 677 Arrowood Ct., Los Altos,
on Friday Oct 14 at 7:00 pm. A buffet dinner will be served.
Please bring something to drink, soft drinks, beer or wine,
according to your taste.
RSVP
Tom Binford
941-9715
∂11-Oct-77 1414 RPG
To: MACLSP.DIS[AID,RPG]:;
Modifications to Step (1 bug fixed; 1 feature added):
1. Use (step) as in the manual. That way (step t) inside a break
should work.
2. New feature: (step-hard ...) which is just like step EXCEPT it
works HARDER! Now, working harder is really true so don't use it
unless you need it. Here's what it does: suppose you have
(defun foo (n) ... (bar ...) ...) and foo is compiled and bar
isn't, and you want to step wherein bar. Well, since eval never sees
the compiled call to bar, ordinary (step (wherein bar)) will lose.
But, if you are stepping-hard, the stepper looks around the FIRST
chance it gets to see if it is inside of BAR; this means it searches
the control stack. If it is in bar it prints
<in BAR>
next-form.
-rpg-
∂11-Oct-77 1928 LLW via AMET SAIL Proposal for S-1 Project Participation
To: JMC, LES
CC: TM, LCW, LLW
A month has elapsed since we last spoke about SAIL participation in the S-1
Project during the current year (FY78). My understanding at the conclusion
of the last meeting was that SAIL would draft up a statement of its
interests along these lines, together with a schedule of the resources it was
able to commit to this work, in the form of a proposal to LLL on which we
could then iterate relatively quickly to formalization of the working
relationship.
I haven't heard from anyone representing SAIL since this meeting of a month
ago, and don't know whether this represents a communications failure at my
end of things, difficulties encountered on your end, or whatever. For my part,
I would still very definitely like to have SAIL participate in
the S-1 Project in a mjaor way, commencing in the very near future. If,
however, SAIL interests and/or commitments have changed since we last spoke,
I will appreciate hearing of this as soon as possible, so that I can
make alternative arrangements for those aspects of the Project in which you
have expressed interest.
If SAIL is still interested along the lines previously discusssed, and moreover
would be interested in commencing work along these lines in the comparatively
near future, my having at least an early 'draft' proposal in hand in the very
near term is quite essential, as there are irremedially large time
delays in processing large sub-contracts through the LLL and DoE bureaucrac-
ies, and the associated clocks need to be started at the earliest possible time.
Could one of you please drop me a note concerning SAIL interests along
these lines and, if it's basicallly affirmative, a draft proposal shortly
thereafter? Thanks.
Lowell
Lowell:
There has been no communication problem. I have been away, and both
Ralph Gorin and Jeff Rubin have had major debugging crises. Nevertheless,
we have to get together in the next few days and see what we can propose.
John
∂13-Oct-77 1155 CR Inventory Info Needed
For our inventory we need the serial numbers and the govt. tag numbers from
the Imlac Display and Modem at your home. Please supply this info as soon as
possible.
The Imlac doesn't belong to the government and never did. The modem
has serial number 7649 NFPA Type II. It has a government tag that says
SD-183 and Contract No. 00746, but it may belong to Stanford by now, since
we had it before they gave us a the KA-10, etc. The Imlac is serial no. 12.
∂13-Oct-77 1326 LES S1 meeting
It turns out that REG can't make it at 4pm today. Rescheduled to 2pm Friday, OK?
∂13-Oct-77 1609 TOB
To: JMC, LES, PAT
Reminder about party 7pm Friday
∂13-Oct-77 1945 LCW Acknowledgements
To: LES, JMC
CC: LCW
The S-1 project is about to generate a new architecture and implementation
description. We of course want to properly acknowledge the
Stanford AI Project. I would like LES to mail me the names of
agencies and/or contract numbers which should be used in the
SAIL acknowledgement.
Curt
∂14-Oct-77 1000 JMC*
letters to Dennett and Putnam. telephone Simon.
∂14-Oct-77 1013 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 14 OCT 1977 1312-EDT
From: CARL at MIT-AI (Carl Hewitt)
To: CARL at MIT-AI, jmc at SU-AI
Hi John,
I don't know whether my previous messages got through to you or not.
How is your history of LISP coming along. If you tell me the path
name where it is on your directory I will give you feedback.
Also we need to think of appropriate referees for the paper.
Preferably the referees would be people who had actual first hand
knowledge of the historical events.
Do you have any suggestions as to logical candidates?
I haven't written it yet, but it won't take long. Jean Sammet is taking
a very bureaucratic attitude on the matter of inviting Stoyan. I need
to campaign about it with the program committee. Could you phone me
or say when I can phone you?
∂14-Oct-77 1538 MRC Host-host protocol
To: JMC, LES
CC: PAT
Give me a little bit of time to edit the host-host protocols before Patte
sends 'em to the Bell Labs guy. Dave Moon just gave me 92 lines worth of
corrections to be made and that will allow me to clean things up somewhat.
I should have it ready soon.
∂15-Oct-77 0139 TVR
To: JMC, DON
Hint: It's not a cryptogram.
Also, beware of orange.
∂15-Oct-77 2017 FTP:MRC at MIT-AI (Mark Crispin)
Date: 15 OCT 1977 2315-EDT
From: MRC at MIT-AI (Mark Crispin)
To: Les at SU-AI
CC: JMC at SU-AI, MRC at SU-AI
Here are RMS' comments about multiplexed connections, which you
said was a bad idea. Do you have an answer to this?
RMS@MIT-AI 10/15/77 14:36:32
I think that you will be screwd considerably in the future
if you don't allow NOW in the host-host protocol for
multiplexed connections. You can make it optional for
a host to implement them. But there is no reason why
a big central server shouldn't implement them when talking
to another big machine. Just add a new error code
"I can't handle two connections at once" and say that it
is legitimate to complain that way to a second RPC.
The large computer, getting that response, could make the
requesting process wait for the existing connection to close.
A small computer would presumably not try to use two connections
at once, so if it got that reply it would send a Reset and try again.
Doing things this way means that small machines don't have to
be burdened with multiple connection hair but as they grow
they can expand into it whenever their hackers think it's worth it.
Also, there are already 9600 baud modems - expensive, it is true.
But do you want DIALNET to be obsolete in 5 years?
The voice network doesn't allow multiplexed connections, because the
probability that two users will be talking to the same other place is
low. After Dialnet is well established, there will be a great variety
of places to which people talk. Having several Dialnet ports will therefore
be of greater priority for a large system than making one port handle
several connections at once. All this depends to some extent on how
much trouble it is to implement multiple connections, and how much difficulty
providing for multiple connections makes for inexperienced system
programmers who only want to implement single connections.
∂17-Oct-77 0846 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 17 OCT 1977 1144-EDT
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
Dear John,
Thanks for the draft. I will write comments on it an mail it back to you.
Where do you want me to put it in your file system? Perhaps I could just
mail it but perhaps the mail system will not accept a file that big.
Carl
Call it lisp.com[f77,jmc]. I wrote it in one session, so it doesn't take
into account everything that is wanted, but not all of that it relevant.
It probably should have more history to balance the pre-history, but I
think that the development of the ideas is important in the history of
LISP, and I can't help that it makes the article unpleasantly self-centered.
∂17-Oct-77 0952 TOB hello
This is Ira Goldstein.
John, If you will be at SAIL later this morning, it would be fun to get
together and chat re my latest work on learning logic. I will be first with
TOB and later with Cordell, and probably here at SAIL until 12:30.
Ira
Unfortunately, I have an appointment at 11 far away. It is marginally
possible that I will be back by 12:30, but then I will be in all afternoon.
∂17-Oct-77 1124 TOB From Ira Goldstein re getting together
As it turns out, ' probably will be here this afeternoon.
I will come looking for you circa 1:30.
∂17-Oct-77 1218 DCL
To: GROUP.DIS[VCG,DCL]:;
THERE WILL BE NO VERIFICATION SEMINAR THIS WEEK
∂18-Oct-77 0822 FTP:LISKOV at MIT-DMS Stoyan
Date: 18 Oct 1977 1120-EDT
From: LISKOV at MIT-DMS
Subject: Stoyan
Message-id: <[MIT-DMS].60158>
Carl and I discussed the Stoyan situation and agreed that
a letter of invitation could be justified on the grounds that
we may want him as a discussant and without the invitation now
he couldn't possibly come. Jean is in Seattle, so I haven't
been able to discuss this with her yet. She'll be back
on Thurs. or Fri. and hopefully will agree.
It might be a good idea if I had some wording to propose.
Have you any suggestions? Barbara
∂18-Oct-77 0859 CR Telephone Message
Della VanHeyst from the Alumni Office (7-2021) called. She will try to call again
between 3 and 4.
∂18-Oct-77 0930 DPB Theory Qual
To: JMC, ZM
The theory qual which was postponed last spring should be scheduled. We
probably want to give the students about a month's notice, so we should
pick a date very soon. -Denny
∂18-Oct-77 0933 FTP:Feigenbaum at SUMEX-AIM Stanford HPP participation in TV broadcast
Date: 18 OCT 1977 0928-PDT
From: Feigenbaum at SUMEX-AIM
Subject: Stanford HPP participation in TV broadcast
To: hart at SRI-KL, raj.reddy at CMUA, raj.reddy at CMUB,
To: newell at CMUA, jmc at SAIL
cc: buchanan, lenat at CMUA, phw at MIT-AI
To: Colleagues in various places
From: Ed Feigenbaum
Subject: Stanford Heuristic Programming Project participation
in the "Nova" TV film on Artificial Intlligence.
Dear friends,
The purpose of this note is to let you know that Bruce Buchanan
and I have declined to volunteer our time and effort for
the projected "Nova" PBS-TV program on AI; and to indicate
briefly our reasons, in case you're interested.
We did a great deal of soul-searching, spent many hours discussing
this with Stanford faculty and students, including Professors
Berg and Cohen, who were on the Nova program on recombinant
DNA research, and Professor Lederberg, our main collaborator
(Prof. Cohen is, by coincidence, also the co-principal investigator
of the MYCIN project).
In the end, we felt:
1. that there was too much risk to our projects and to AI from
a wide TV exposure that was not under the control of AI scientists.
From what we heard and what we have seen of past programs, "Nova"
likes to deal in controversy about science rather than in science
itself (e.g. recombinant DNA program, nuclear power program); and
the last thing we want to do is to raise the profile of AI by
engaging in public controversy (particularly in a format over
which we have no control). We also believe that the time is not right
for public controversy about AI,i.e. arguments about societal
impact are premature and will hurt us severely in the science
funding agencies at this point. The few soundings I have taken
on this point indicate "strong downside risk."
2. The ratio of benefit-to-AI/cost-to-us-in-time will be too
low to make it worthwhile. The participation of Berg and Cohen
was each measured in days (!); each man felt that the "coloration"
his views provided to the overall picture was negligible,and
not worth the effort.
We have summarized the comments of Professors Berg,Cohen, and
Lederberg. Since my purpose in writing was to inform you of our
decision and its reasons, and not to persuade you to any position,
I have not included these summaries. However, if any of you
want to see the comments, please drop me a net note (feigenbaum
at sumex-aim) and I will send the files. I ask only that you
keep these remarks and summaries confidential (please!).
With best regards,
Ed Feigenbaum
(Feigenbaum at sumex-aim)
-------
∂18-Oct-77 1415 ZM Theory Qual
To: DPB, JMC, WP, MFB, CG
The Theory Qual will be held on Sat.,Dec. 3. It will be an oral exam.
∂18-Oct-77 1503 TK via AI LISP[F77,JMC]
Carl mentioned this file to me. It appears that it is intended for publication.
Do you know where yet? I would like to be able to reference it before the fact.
It is a first draft of a paper to be given next June at a conference on history
of programming languages. Carl or Barbara Liskov can tell you more about the
conference. I welcome corrections or suggestions for improvements. The present
draft was written in one sitting, and doesn't contain information about other
people's contributions that will be in later versions.
∂18-Oct-77 1719 BPM
To: WD, JMC, Feigenbaum at SUMEX-AIM, Lederberg at SUMEX-AIM
To: Buchanan at SUMEX-AIM, CCG, TW, LES, DEK
"Page One Advisory"
4:26 pm, 18 October 1977
The New York Times plans the following Page One, first edition,
Wednesday, Oct. 19:
TOP:
Stuttgart(Times) 3 imprisoned terrorists commit suicide. (3 cols)
(2-col cut hostages and commandos return to West Germany.)
Wash(Jensen) SEC orders probe of stock options trading.
Wash(Rattner) White House unveils plan for storing nuclear wastes.
FOLD:
(3 one-col cuts dead West German terrorists.)
Bonn(Times) Rescue of hostages was complex international effort.
→→ New York(Browne) Secret-code researchers charge NSA harasses them. ←←
Port Edward, N.Y.(Severo) Funds lacking to clear PCBs from Hudson.
BOTTOM:
London(Apple) Pilots to strike to protest lax airliner security.
(3-col cut West German commandos.)
New York(Brody) Birth-pill users have sharply higher death rate.
(1-col cut Crosby funeral. Story inside.)
"Code"
by MALCOLM W. BROWNE
(c) 1977 New York Times News Service
4:34 pm, 18 October 1977
NEW YORK - Computer scientists and mathematicians whose research
touches on secret codes say they have been subjected by the National
Security Agency to growing harrassment and the threat of sanctions or
even prosecution for publishing articles about their work.
The scientists, some working for universities, some for private
industry and some for the government, charge that research in this
country faces a muted but growing threat from the NSA - the
government's highest authority on secret codes.
NSA tactics, they say, may eventually mean that a scientist working
outside the government could suddenly be informed his work had been
classified officially as secret, or he could be constrained from
participating in international professional meetings.
Norman Boardman, spokesman for the NSA, told The New York Times that
neither he nor any other employee of the agency could comment in any
way on the accusations made by the scientists.
Complaining scientists, lawyers for scientific institutions and
government experts agree that laws covering such potential
constraints are ambiguous. But because of the vagueness of the
current legal position, NSA threats and pressure must be taken
seriously, they assert.
Scientists said in interviews that threats levelled against them by
employees of the NSA have included the possibility of official action
to get research grants canceled or criminal prosecution for violation
of security laws.
A source within the National Science Foundation, a federal agency
that underwrites many research programs by private organizations and
individuals, said his organization was being subjected to increasing
''systematic, bureaucratic sniping'' from NSA with a view to bringing
certain kinds of research under NSA control.
The informant, who requested that his identity not be disclosed,
said that there was a real danger of intimidating a large segment of
the private American scientific community if NSA pressure were not
resisted.
Such allegations have been simmering in the scientific press for the
last six months, but the controversy was brought to a boil by a
symposium on information theory held last week at Cornell University
in Ithaca, N.Y.
Among the scientists who presented papers at the meeting was a group
from Stanford University headed by Dr. Martin E. Hellman and an
associate, Whitfield Diffie.
The Stanford group had been concentrating its studies on a kind of
mathematical problem known as the Nondeterministic Polynomial
Complete Problem (N-P Complete).
(An example of such a problem would be the fitting of several forms
of varying shapes and sizes into a larger form, with no excess and
nothing left over).
The N-P Complete problem's special interest to computer scientists
is that at this point no computer can be programmed to solve it.
Hellman and his associates have therefore proposed it as a device for
''locking'' data stored in the memory banks of computers against
unauthorized use or theft.
''The right to privacy of the American citizen is what this is all
about,'' he said.
However, the N-P Complete problem could also be used as a system for
devising secret communications codes that, Hellman contends, would
also be virtually impossible to break, even by giant intelligence
organizations, including the National Security Agency.
The implication, Hellman and others said, was that any government,
private organization or individual could devise and use a code that
would be immune to eavesdropping, whether from the Central
Intelligence Agency, the Soviet Union's counterpart the KGB, or any
other group.
This, say the experts involved, created anxiety within the United
States intelligence community in an interview, a senior government
intelligence official described the issues raised by the Hellman team
as ''extremely serious'' to the national security interests of the
country.
The Stanford work and related projects by the Massachusetts
Institute of Technology and others, he said, could enable foreign
powers to develop virtually impenetrable command-and-control military
communications systems.
Most computer scientists and mathematicians in the United States are
members of the Institute of Electric and Electronic Engineers, which
publishes their papers and distributes them to countries abroad,
including the Soviet Union.
Several weeks before the Cornell conference, the Institute received
a letter from one of its members, Joseph A. Meyer, who is listed,
well-placed scientists say, in the National Security Agency directory
as an employee.
The letter warned the Institute that publication and distribution of
scientific papers by the Stanford team and other groups planning to
participate in the Cornell conference could result in prosecution
under the 1954 Munitions Control Act, known in its current revision
as the Arms Export Control Act.
Lawyers of the institute studied Meyer's letter and the law itself,
and finally concluded that they were within the law in publishing the
Stanford research. A similar view was taken by lawyers representing
Stanford University and officials interviewed by The New York Times
in the Department of Commerce, the agency responsible for issuing
licenses for exported technology.
But Meyer's letter cast a pall over the Cornell conference,
participants said, and several postdoctoral students were dissuaded
from presenting their own papers.
''I have tenure at Stanford,'' Hellman said, ''and if the NSA should
decide to push us in court, Stanford would back me. But for a student
hoping to begin a career, it would not be so pleasant to go job
hunting with three years of litigation hanging over your head.''
Boardman, the security agency spokesman, denied that the NSA had
directed any employee to bring pressure on Hellman or the others.
But an informant in the National Science Foundation said the letter
from Meyer to the engineering institute was merely one of a number of
similarly threatening letters that had been sent to scientists and
their organizations by known employees of the security agency.
''I have also had private conversations with NSA,'' he said, ''in
which they have threatened all kinds of things, including getting
research grants cut off to offending scientists. Many of these
threats have absolutely no legal basis, of course, but the target
scientists are not lawyers, and they don't know where they stand.''
∂18-Oct-77 1836 TOB copier
To: LES, JMC
I am told that SRI's IBM copier can duplicate
photos and doesn't jam. We might consider
replacing Xerox.
Tom
∂18-Oct-77 1855 DON
To: TVR
CC: JMC
∂15-Oct-77 0139 TVR
To: JMC, DON
Hint: It's not a cryptogram.
Also, beware of orange.
[Don't bother sending me hints--I won't have time to look at ZORK for a while
and I don't want to be biased.]
∂18-Oct-77 1858 HPM OOPS
I was so caught up in the mechanics of making the movie that
the content temporarily slipped my mind. The credits will be
reshot with an "Idea originator" line. There wasn't time to do
it for the conference, but I inserted it verbally.
∂20-Oct-77 1204 CR Telephone Message
Lloyd Glicken from American News Service called and would like you to return
his call either this afternon or tomorrow. His number is [304] 876-2251 and
he will be in his office until 6:00 p.m. Eastern Standard Time.
∂20-Oct-77 1644 LES Carlson visit
Bill Carlson's Secretary called to say that he wants to visit me on October 26
at 11:30 am. Topic is undefined, but probably budgeting.
∂20-Oct-77 2054 CDR via AI lisp history
John,
I succeeded in transfering the file from your site. I got a protection
violation on MITAI. My comments are delimited using ***. In general
I think that it is a good first draft except that the beginning is
rough.
Cheers,
Carl
∂21-Oct-77 0015 REM via AMET Hellman, one-time pads, public-key-systems
In deciding whether theone-time pad is useful for anything, it doesn't
matter that there are things other systems can do that it cannot, nor
even whether there are things that it can effectively do. What matters
is whether there is anything it can do that no other system can do except
for a much higher cost. It seems to me that public-key codes using
a pair E1,D2 when transmitting messages from person 1 to person 2, IF
SECURE AS BELIEVED, is cheaper and at least as good as a one-time pad.
Rebuttal?
No rebuttal - if secure as believed. E1,D2 system must be modified to
achieve the result that a correct guess can't even be confirmed, but
this just involves adding random nulls in sufficient quantity.
∂21-Oct-77 1244 REP Boden's Book
Please keep the book for as long as you like. I have not had a chance
to read the book and do not see any free time for the next week or two.
Rich
Many thanks. I am about a third of the way through it, and it seems to
be excellent.
∂21-Oct-77 1333 CGN MACLISP MACRO PACKAGE FOR RECORD STRUCTURES
To: MACLSP.DIS[AID,RPG]:;
I have finished a macro package written by Derek Oppen and myself to
facilite manipulating record structures with named components.
As an example, the call (SHELL MNODE COEF UP LEFT ROW COL) could be
used to "create a data-type MNODE" for sparse matrix nodes which has
five components, by defining access and update macros for the
components and an allocation function for MNODEs. You have your choice
between list-structure or MACLISP hunks for the underlying
representation.
The package is documented in SHELL.LSP[LSP,CGN].
∂21-Oct-77 1417 RAK
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR TUESDAY 1 NOVEMBER
PLACE: ERL 237
TIME: 2.00 pm.
Tuesday, November 1
Note--this is not next week but the week after!
TITLE: EFFIGY and Symbolic Execution
*********************************************************
SPEAKER: JIM KING
Our particular notion of symbolic execution as implemented in
the EFFIGY System will be explained. Symbolic execution will be
promoted as a useful program analysis tool, with examples taken from
our EFFIGY experiences. EFFIGY now has four "modes" of program execution
including: interactive execution, testing (automatic tree walker),
test coverage analysis, and correctness proof. The first two may be
used on programs having assertions in which case the assertions
are checked in each instance they are encountered.
A cute (ED NOTE: CUTE?!?) way of providing a lemma capability for
subprograms which we call "abbreviated procedures" will be explained.
As a grand finale for those of you who don't already know we will explain
the derivation of the name EFFIGY.
∂21-Oct-77 1451 JMB colloquium
We spoke at one time about your giving the CS Tuesday
colloquium. I would like to have your talk on
November 1 if that is possible.
....Jeff
∂21-Oct-77 1530 HVA Informal NSF Visit & Tour of A.I. Lab
CC: LES, JMC, TOB, TW, ZM, JC
Two persons from NSF (probably accompanied by Earl Cilley),will be on Campus
Tues. 10/25 and Wed. 10/26 (to discuss large SLAC project funding), and they
want to visit A.I. Lab. We won't know actual time of visit to A.I. until Tues.
morning, but Les is holding TUESDAY, Afternoon, OCTOBER 25th, from 1 - 5 p.m.
and WED. morning, OCTOBER 9 - 11 a.m. for Tour. I'll let you know precise
time as soon as I know it; the visit probably won't take more than 1 hour.
∂23-Oct-77 0000 MRC REM
To: REG, JMC
You may not know this, but REM has moved some of the PCnet software to LOTS
tonight logged in as GUEST. I figured I should inform you of this.
∂23-Oct-77 2152 PAT San Diego
To: HVA, CR, CJS, LES, JMC
I will be leaving for San Diego on the 24th. I will take the
train to LA and will be staying Monday night at the LA Hilton.
Tuesday morning I will fly to San Diego at 9:30. That evening
I will be staying with Lester's parents (714) 296-6094.
Thereafter until Monday I will be at San Elijo State Beach - (714) 753-5091.
The conference is being put on by the Center for Music Experiment,
UC San Diego, La Jolla. You should be able to reach me through them.
∂24-Oct-77 0958 MTK Request for SAIL account
I have been associated with SAIL informally for several years,
and have had a mostly inactive account ([1,MTK]) since
1972 or 3. Currently, I am active with the PCNET Protocol group
and have one of the microcomputer test nodes.
Indications are that I am about to be purged from the system. I would
appreciate being allowed to continue as a user. I use almost no time
and very little file space (less than 3K normally).
... Marc Kaufman (ex-C.S. grad student, DSL Acting Asst. Prof., Instructor)
∂24-Oct-77 1712 JBR
To: MRC
CC: JMC
You were not hired to rewrite TELNET. Why don't you make DIALNET
work first.
∂24-Oct-77 1727 JMB CS Colloquium
I sent you mail last week about presenting a colloquium, but I think
that you did not receive it (possibly due to my error or a system
crash). If you are interested in giving a colloquium, I am
having some difficulty filling the slot on Nov. 1and I would
like you to take that day.
If you are interested, I will expect mail.
....Jeff
I received your previous message. Regrettably, Nov. 1 is too soon
for me.
∂24-Oct-77 2144 FTP:LISKOV at MIT-DMS Stoyon
Date: 24 Oct 1977 1652-EDT
From: LISKOV at MIT-DMS
Subject: Stoyon
Message-id: <[MIT-DMS].60492>
Dear John, Jean is willing to send a letter with
something approximating the following paragraph:
The programming committee may invite selected people
to act as discussants for the different languages. You have
been recommended as a possible discussant for Lisp. However,
a decision about discussants will not be made until December.
We understand that you must begin making preparations to
attend the conference in early November. Therefore, we
suggest that you begin your preparations now, so that you will
be able to accept a position as discussant, should we decide to
invite you.
I doubt that Jean will agree to send something much
stronger than this. Do you think such a paragraph will
be helpful to Stoyon? Or is it possible that such a
letter will be worse than doing nothing? If you can
suggest small changes in wording that might help, please
do so.
Barbara
Tom Cheatham has agreed to talk to Jean and other members of the
committee. Let's see what comes of this before accepting this
weak response.
∂24-Oct-77 2144 FTP:BOBROW at PARC-MAXC THE RUSSIANS ARE COMING TOMORROW MORNING (TUESDAY) AT 9:30
Date: 24 OCT 1977 2016-PDT
From: BOBROW at PARC-MAXC
Subject: THE RUSSIANS ARE COMING TOMORROW MORNING (TUESDAY) AT 9:30
To: JMC at SAIL
A REMINDER. I will be expecting them over at PARC after lunch (about 1:30PM)
danny
-------
∂24-Oct-77 1713 MRC
To: JBR
CC: JMC
∂24-Oct-77 1712 JBR
You were not hired to rewrite TELNET. Why don't you make DIALNET
work first.
[MRC - That's why I said it was on the queue, instead of saying that I
was doing it. For me, being "on the queue" means inactive and only
future plans.]
∂25-Oct-77 0954 DPB Committee Assignments October 25, 1977
To: FAC.DIS[1,DPB]:;
CSD Faculty
Denny Brown
Committee Assignments for 1977-1978
This information and other information relating to committees can be found
in the file COMMIT.INF[1,DPB] at SU-AI.
Admissions: Golub, Herriot (Co-Chairman), Luckham, McCluskey,
Tarjan, Dale, 2 students.
(Student volunteers in chronological order. Golub will choose two.)
77/78--Dick Gabriel (RPG), Bill Scherlis (WLS), Ron Goldman (ARG),
Sam Bent (SWB), Bob Filman (REF), Al Spector (AZS), Eric Grosse (EHG)
Colloquium: Barth, Herriot, Oppen, Lansky
Comprehensive:
Winter 1/78: Floyd, Dantzig, Green, (plus one systems member to be
named), Sam Bent (SWB), Doug Appelt (DEA)
Spring 5/78: F.Yao, Barth, Golub, McCarthy,
Dan Boley, (plus one more student member.)
CSCE: McCluskey, Oliger, vanCleemput, Nye.
Computer Forum: McCluskey, Terry Roberts (TLR)
Library & Publications: Buchanan, Earnest, Fahrenholz, Davidson
Curriculum: Floyd, Green, Wiederhold, D.Brown, Luckham,
McCarthy (ex off. as LOTS director), Doug Appelt (DEA)
Facilities: King, Feigenbaum, Earnest, McCarthy, Floyd,
(formerly Building and Scott, 2 Students.
Computer Systems Requirements)
Fellowships & Awards: Green, Strong
The following committees need volunteers:
Committee Chair Volunteers wanted.
----------------------------------------------------------------------------
Colloquium Barth Volunteer if interested.
Curriculum Floyd Volunteer if interested.
Library & Publications Buchanan Volunteer if interested.
Facilities(Building & Computing) King Volunteer if interested.
∂25-Oct-77 1040 HVA NSF TOUR OF AI CANCELLED
CC: LES, JMC, TOB, TW, ZM, JC, DCL
Per Sponsored Projects, the A I Tour announced in my message of 10/21, had
to be canceled due to lack of time.
∂25-Oct-77 1714 JBR
You have exceeded your disk quota.
The files listed below have been purged to reduce your disk
area to your quota of 2000
Before purging, your files occupied 2628
You have too many files. The purger may not select the
optimum set.
SIGART.LST[LET,JMC]
ENERGY.LST[LET,JMC]
LEADER.LST[LET,JMC]
AIQUAL.LST[W77,JMC]
NEWELL.LST[LET,JMC]
GTREE.LST[206,JMC]
DIALNE.LST[DIA,JMC]
CRYPT.DMP[ 2,JMC]
CODE.DMP[ 2,JMC]
SOURC2.LAP[ 1,JMC]
2P.LAP[W77,JMC]
REPRES.PRO[ 1,JMC]
FUNS[ 1,JMC]
EPIS[ 1,JMC]
P1[ 1,JMC]
PART[ 1,JMC]
PERM[ 1,JMC]
PATH2[ 1,JMC]
PATH[ 1,JMC]
ANTIN[ 1,JMC]
SYLL[ 1,JMC]
MEET[ 1,JMC]
COMPIL[ 1,JMC]
TIMES[ 1,JMC]
TESTA.SAI[ 1,JMC]
TESTC.SAI[ 1,JMC]
TESTB.SAI[ 1,JMC]
TESTD.SAI[ 1,JMC]
DADDA[ 1,JMC]
ORDIN[ 1,JMC]
PROB1[ 1,JMC]
ROTAT.SAI[ 1,JMC]
ROTA.SAI[ 1,JMC]
ROTB.SAI[ 1,JMC]
ROTC.SAI[ 1,JMC]
SEMAA[ 1,JMC]
SEMAB[ 1,JMC]
INTER[ 1,JMC]
CONVER.SAI[ 1,JMC]
RELREP[ 1,JMC]
MC[245,JMC]
FWGC[245,JMC]
PATH[245,JMC]
PATH2[245,JMC]
DEMO[ 1,JMC]
LISPAD[ 1,JMC]
TESTE.SAI[ 1,JMC]
ICOM[ 1,JMC]
TRANS1[ 1,JMC]
SIMUL[ 1,JMC]
COMPU2[ 1,JMC]
SOURCE[ 1,JMC]
SOURC2[ 1,JMC]
PUZZ.SAI[ 1,JMC]
TCLUB[ 1,JMC]
TCLUBA[ 1,JMC]
NEWDOC[ 1,JMC]
BOARDS.SAI[ 1,JMC]
REFER.ENC[225,JMC]
MCCRAC.LET[ 1,JMC]
PATHS.RLS[225,JMC]
PARKER[ 1,JMC]
GRPDAT.RLS[225,JMC]
GRPALG.RLS[225,JMC]
GROPER.RLS[225,JMC]
DIMEN.RLS[225,JMC]
CHAR.RLS[225,JMC]
LARRY2[ 1,JMC]
COMPU2.LET[ 1,JMC]
DEG5.IN[225,JMC]
REPRES.RLS[225,JMC]
S4.REP[225,JMC]
DEG6.IN[225,JMC]
R42.IN[225,JMC]
PUZZ.SAI[225,JMC]
PUZZA.SAI[225,JMC]
PANIC.SOS[225,JMC]
ANNOUN[225,JMC]
PUZZB.SAI[225,JMC]
ENCYC1.PRO[ESS,JMC]
PUZZE.SAI[225,JMC]
PTCH2.DIR[ AI,JMC]
DRIVE.DIR[ AI,JMC]
MINE.DIR[ AI,JMC]
KNOW2.AI[ESS,JMC]
ARTNA1.ART[ESS,JMC]
RECOG.LET[ 1,JMC]
MEMMTC.QUA[ESS,JMC]
LANG1.AI[ESS,JMC]
MTC71.QUA[ESS,JMC]
S5.QUA[ESS,JMC]
R1301.ART[ESS,JMC]
R1303.ART[ESS,JMC]
N30[ 1,JMC]
QA.PRO[ESS,JMC]
ARTNAT.ART[ESS,JMC]
SEMAN.AI[ESS,JMC]
FRANK.STA[ESS,JMC]
COMPUT.STA[ESS,JMC]
MTCSYL.QUA[ESS,JMC]
AISY69.QUA[ESS,JMC]
FILEC.FAI[ESS,JMC]
LETTVI.REV[ESS,JMC]
R1300.ART[ESS,JMC]
LCFMEM.MTC[ESS,JMC]
PEARL.NOT[ESS,JMC]
PUZB.SAI[226,JMC]
PUZZ.RLS[226,JMC]
PUZZ.SAI[226,JMC]
TRANS.DOC[226,JMC]
BLISET.COM[226,JMC]
BLISET.PRF[226,JMC]
IMPROV.DOC[226,JMC]
SETRUL.DOC[226,JMC]
PCHECK.M2[226,JMC]
COND.PRF[226,JMC]
BACKSL[ 1,JMC]
SYSTEM.HAC[226,JMC]
SORTS.DOC[226,JMC]
TH1.COM[226,JMC]
PCHECK.M1[226,JMC]
ADD.COM[226,JMC]
ADD.PRF[226,JMC]
TH1.PRF[226,JMC]
NETJO2.PRO[ESS,JMC]
DI[226,JMC]
FALSE.PRF[226,JMC]
SCWORL.AX2[226,JMC]
ONE.PRF[226,JMC]
IPT73.REP[ESS,JMC]
NSFX.6[ESS,JMC]
NSFX.5[ESS,JMC]
NSFX.7[ESS,JMC]
NSFX.9[ESS,JMC]
NSFX.2[ESS,JMC]
NSFX.8[ESS,JMC]
NSFX.3[ESS,JMC]
NSFX.4[ESS,JMC]
HAYES.FRM[ESS,JMC]
ADTEL2.NOT[ESS,JMC]
PLATT.NOT[ESS,JMC]
REPRES.BIB[226,JMC]
ONTO.NOT[226,JMC]
TASK1.MAR[ESS,JMC]
TASK2.MAR[ESS,JMC]
LETTER.HE2[ESS,JMC]
XLET[ESS,JMC]
ZF.AX[ESS,JMC]
FOO73A[ESS,JMC]
FOON.PR1[ESS,JMC]
ROTD.SAI[ 1,JMC]
ROTE.SAI[ 1,JMC]
ROTF.SAI[ 1,JMC]
SWOPSI.RE[ESS,JMC]
HART.ME1[ESS,JMC]
GGGG[ESS,JMC]
PRO[ESS,JMC]
M29AUG.MES[ESS,JMC]
SYMPOS[ESS,JMC]
CH1.BH2[ESS,JMC]
CLOCK.FAI[ESS,JMC]
FONTS[ESS,JMC]
SLIDES[ESS,JMC]
FACMIN.MEM[ 1,JMC]
W74.PLN[226,JMC]
CLASS.REG[226,JMC]
GAME.CHK[226,JMC]
FOO1[ESS,JMC]
FOL2.MEM[226,JMC]
FOL1.MEM[226,JMC]
WUTHER.QUE[ESS,JMC]
ROY[LET,JMC]
FORDH.LET[LET,JMC]
TOLLES.LET[LET,JMC]
AD.NET[ESS,JMC]
KNUTH.SAI[225,JMC]
NEWRUL.DOC[226,JMC]
COMPUT[ 1,JMC]
TUCKER.LE2[LET,JMC]
TOLLES.LE1[LET,JMC]
TUCKER.LET[LET,JMC]
TCLUB.MEM[ESS,JMC]
NOTES2[ AI,JMC]
PUTCH3[ AI,JMC]
RUSS[ AI,JMC]
CHYLIN.LE1[ AI,JMC]
GEN1[ AI,JMC]
DRIVE3[ AI,JMC]
MPRO[ AI,JMC]
PUTCH[ AI,JMC]
PUTCH.DIR[ AI,JMC]
DRIVE[ AI,JMC]
AIBIB[ AI,JMC]
MINE[ AI,JMC]
BOWDEN.LE1[LET,JMC]
SLAMEC.LE2[LET,JMC]
CHERN.LE2[LET,JMC]
MAY.ME[LET,JMC]
NSFX.10[ESS,JMC]
MC.AI[ESS,JMC]
HENRY[ESS,JMC]
BIRKHO.LE1[LET,JMC]
ERIK.LE6[LET,JMC]
FLANAG.LE1[LET,JMC]
TAMBOV[ 1,JMC]
BARAB[ 1,JMC]
HARPER.LE1[LET,JMC]
PUZZE.F4[225,JMC]
BAJCSY.LE1[LET,JMC]
ERIK.LE7[LET,JMC]
STARKM.LE1[LET,JMC]
BRIT.LET[LET,JMC]
MT[ 1,JMC]
IRANI.LE1[LET,JMC]
BOWEN.LE1[LET,JMC]
JAF.STA[ESS,JMC]
RECUR[ESS,JMC]
ANDERS.RE1[ 1,JMC]
PEOPLE[226,JMC]
JERRY.LE1[LET,JMC]
MCQUIL.LE1[LET,JMC]
PAM.LE1[LET,JMC]
DRLUK.LE1[LET,JMC]
OCT.ME[LET,JMC]
OLSEN.LE1[LET,JMC]
ERIK.LE0[LET,JMC]
SUBCOM.LE1[LET,JMC]
MICHIE.LE2[LET,JMC]
NEWSCI.LE1[LET,JMC]
AHLHAU.LE1[LET,JMC]
MEMOS.CUR[LET,JMC]
PUBINT.LE1[LET,JMC]
HORNIN.LE1[LET,JMC]
FELDST.LE1[LET,JMC]
CHECK.DEP[LET,JMC]
TUCKER.LE1[LET,JMC]
SCANDU.LE1[LET,JMC]
MELTZ.LE1[LET,JMC]
PIASET.LE1[LET,JMC]
MILNER.REC[LET,JMC]
FLESS.LE1[LET,JMC]
TRESSL.LE1[LET,JMC]
PIASET.LE2[LET,JMC]
LICKL.LE1[LET,JMC]
COOP.LE1[LET,JMC]
LICKL.LE2[LET,JMC]
POE.LE1[LET,JMC]
JMILLE.LE2[LET,JMC]
IGARAS.LE1[LET,JMC]
ITO.LE1[LET,JMC]
CLARK.LE1[LET,JMC]
FLESS.LE2[LET,JMC]
MICHIE.LE3[LET,JMC]
TAVARE.LE1[LET,JMC]
SCIENC.LE1[LET,JMC]
SCRIB.LE1[LET,JMC]
ATKIN.LE1[LET,JMC]
KOCHEN.LE1[LET,JMC]
GREER.FAC[LET,JMC]
CU.LE1[LET,JMC]
RALSTO.LE2[LET,JMC]
MESSAG.SCI[LET,JMC]
MCCRAC.LE2[LET,JMC]
RALSTO.LE3[LET,JMC]
CHRON.LE1[LET,JMC]
LOGIC.QUA[LET,JMC]
SHIGER.LE1[LET,JMC]
PAMELA.LE1[LET,JMC]
TAUGNE.LE1[LET,JMC]
MORGAN.LE2[LET,JMC]
FROOK.LE1[LET,JMC]
LOMONA.LE1[LET,JMC]
APR.ME[LET,JMC]
LOGIC.PUB[LET,JMC]
CONSUL.LE1[LET,JMC]
VERE.LE1[LET,JMC]
PAWLAK.LE1[LET,JMC]
TSUDA.LE1[LET,JMC]
NOLL.LE1[LET,JMC]
ROBERT.LE1[LET,JMC]
RILI.LE1[LET,JMC]
RALSTO.LE1[LET,JMC]
MORGAN.LE1[LET,JMC]
MIYA.LE1[LET,JMC]
HEALTH.LE1[LET,JMC]
WILKS.LE1[LET,JMC]
LAST.LE1[LET,JMC]
SEDEL.LE1[LET,JMC]
CAMPB.LE1[LET,JMC]
ARDEN.LE1[LET,JMC]
BURNS.LE1[LET,JMC]
SHOCK.LE1[LET,JMC]
CU.LE2[LET,JMC]
DAVID.LE1[LET,JMC]
SCHOEL.LE1[LET,JMC]
CALHOU.LE1[LET,JMC]
FINCH.LE1[LET,JMC]
LYKOS.LE1[LET,JMC]
JMILLE.LE1[LET,JMC]
MITCH.LE1[LET,JMC]
FORSHA.LE1[LET,JMC]
STORK.LE1[LET,JMC]
COMPT.LE1[LET,JMC]
R1302.ART[ESS,JMC]
ASTRO2.ART[ESS,JMC]
FRIEDM.LE1[LET,JMC]
FF[ESS,JMC]
AIRLIN.MTC[ESS,JMC]
JFOL.USE[ESS,JMC]
MEARS.LET[LET,JMC]
GRIMM.BKP[ESS,JMC]
SCIAM.LE1[LET,JMC]
NYT.LE1[LET,JMC]
TECH[ 1,JMC]
NAVROZ.LE1[LET,JMC]
LISPN[ 1,JMC]
NOTES1[ AI,JMC]
TXP1.LSP[ 1,JMC]
STARK.LE1[LET,JMC]
IGARAS.LE2[LET,JMC]
REPRES[LET,JMC]
MDAVIS.LE1[LET,JMC]
KNOW.ART[ AI,JMC]
GLUGG[LIT,JMC]
GLUGG2[LIT,JMC]
KNOW.NOT[ AI,JMC]
FLESS.LE0[LET,JMC]
AAAS.LE1[LET,JMC]
MEIR.LE1[LET,JMC]
NAS.NOT[ESS,JMC]
MCCRAC.LE1[LET,JMC]
JAF.LE2[LET,JMC]
KILPAT.LE1[LET,JMC]
LARRY[ 1,JMC]
PERSON[ 1,JMC]
TELLER.LE1[LET,JMC]
PIERCE[ 1,JMC]
YOUNG.LE1[LET,JMC]
JAF.STA[LET,JMC]
CRYPT.FAI[ 2,JMC]
MICHIE.LE1[LET,JMC]
WEISSK.LE1[LET,JMC]
3D.NSF[ESS,JMC]
ONEILL.NOT[ESS,JMC]
AAAS.PRO[ESS,JMC]
ISRAEL.ART[LET,JMC]
ISRAEL.LE1[LET,JMC]
CORBAT.LE1[LET,JMC]
CHENEY.LE1[LET,JMC]
OCTOBE.OUT[LET,JMC]
ONEILL.LE1[LET,JMC]
COMTOP.LIS[ESS,JMC]
CALHOU.LE2[LET,JMC]
COMNEE[ 1,JMC]
EFOO[ESS,JMC]
MICHIE.LE4[LET,JMC]
AIMEM2.JMC[226,JMC]
INFO.NEE[ESS,JMC]
NET1[ 1,JMC]
ALUMNI[ 1,JMC]
EVANS.LE1[LET,JMC]
EVANS.LE2[LET,JMC]
NAMES[ESS,JMC]
INFO[ 1,JMC]
NETDOC.PLN[ESS,JMC]
LIB.PRO[ 1,JMC]
SUFFIC.FRE[LET,JMC]
OCT.USE[ESS,JMC]
OLIVER.LE1[LET,JMC]
INTRO.AI[ 2,JMC]
ADMIS.LET[LET,JMC]
COMMON.NS[LET,JMC]
DRELL.LE1[LET,JMC]
SIGART.BUL[LET,JMC]
SIGART.LE2[LET,JMC]
SIGART.LE1[LET,JMC]
BOWEN.LE2[LET,JMC]
RUSSOF.NOT[ESS,JMC]
INVOIC[LET,JMC]
ACM.LE1[LET,JMC]
ACM.LE2[LET,JMC]
FERRIS.LE1[LET,JMC]
JOSHI.LE1[LET,JMC]
NYT.LE2[LET,JMC]
SOCIAL[ 1,JMC]
AILAB.AIL[ESS,JMC]
BDAY.LIT[LIT,JMC]
EXTFOR.MEM[258,JMC]
ACTOR0[258,JMC]
NONTER.PRB[258,JMC]
CORREC.ABS[258,JMC]
BACKUP.MCP[258,JMC]
HOMOMO.NOT[258,JMC]
MCP.PR1[258,JMC]
COND.PRF[258,JMC]
PQR.PRF[258,JMC]
SCHEM.WRU[258,JMC]
GREEK.JMC[258,JMC]
MCCUS.PRO[258,JMC]
BRACEW.LE1[LET,JMC]
FOLSCO.MEM[258,JMC]
FEMANO.LE1[LET,JMC]
NAUR.LE1[LET,JMC]
MTC.GRP[ESS,JMC]
PETERS.LE1[LET,JMC]
JAN.ME[LET,JMC]
LEGUIN.CRI[LIT,JMC]
SCIFI.CRI[LIT,JMC]
JAN14.DBX[258,JMC]
SUM.CAR[ 1,JMC]
ESSEX.LE1[LET,JMC]
GELLMA.LE1[LET,JMC]
HOBBS.LE1[LET,JMC]
BREMER.LE1[LET,JMC]
SHELDO.NS[LET,JMC]
LOOKUP.SPE[ 1,JMC]
FOLMAN.MOD[258,JMC]
APPEND.CON[258,JMC]
CONSUL.POX[ESS,JMC]
AILET[LET,JMC]
REYNOL.LE1[LET,JMC]
ACM.LE3[LET,JMC]
LEAST.CM1[258,JMC]
NORBYE.LE1[LET,JMC]
JAN.OUT[LET,JMC]
DEC74.IN[LET,JMC]
HAND.2[258,JMC]
JO.NOT[258,JMC]
MTC.BLA[258,JMC]
LOGIC.QUA[258,JMC]
OUTLIN.256[258,JMC]
MANNA.PR2[258,JMC]
MANNA.CM2[258,JMC]
HARDPR.OOF[258,JMC]
OKAMOT.LE1[LET,JMC]
MANNA.WRU[258,JMC]
DEMO.PR1[258,JMC]
HAND3.W75[258,JMC]
HAND.W75[258,JMC]
VIS1[ 2,JMC]
VIS.CAP[ 2,JMC]
NNN[ 2,JMC]
VITASK[ 2,JMC]
CHRI.LE1[ 2,JMC]
VIS[ 2,JMC]
FRAGA.LE1[LET,JMC]
GORDON.LE2[LET,JMC]
FIELDS.ME2[LET,JMC]
ENERGY.LE1[LET,JMC]
GORDON.LE1[LET,JMC]
DEC.ME[LET,JMC]
FEB.ME[LET,JMC]
TASK[LIT,JMC]
ADHOC.THE[258,JMC]
SAKAI.LE1[LET,JMC]
LICK.ME1[LET,JMC]
LICK[ESS,JMC]
LICK.LE1[LET,JMC]
PARTIT.LSP[ 1,JMC]
HAND.1[258,JMC]
BIBLE[245,JMC]
USER[245,JMC]
IDEAS[225,JMC]
SUZUKI.REC[LET,JMC]
SAKAI.LE2[LET,JMC]
MUFTIC.LE1[LET,JMC]
VOR1[ 1,JMC]
ORD1.AX[226,JMC]
LIST.AX[226,JMC]
MCP.AX[258,JMC]
MCP2.AX[258,JMC]
MCP3.AX[258,JMC]
REST.AX[226,JMC]
TERMS.AX[226,JMC]
SET.AX[226,JMC]
INT.AX[226,JMC]
SCWORL.AX[226,JMC]
INTEG2.AX[258,JMC]
COND.AX[258,JMC]
W0.AX[226,JMC]
EQUA.AX[226,JMC]
ORD2.AX[226,JMC]
SEQ.AX[226,JMC]
LISP.AX[226,JMC]
INDUC.AX[258,JMC]
INTEGE.AX[258,JMC]
COMPIL.AX[258,JMC]
ADMIND.AX[226,JMC]
SCOTT.AX[226,JMC]
SET3.AX[226,JMC]
SET2.AX[226,JMC]
BLISET.AX[226,JMC]
ZF.AX[258,JMC]
EQUAL.AX[258,JMC]
EXTFOR.AX[258,JMC]
COND.AX[226,JMC]
IGR.AX[226,JMC]
SCINT.AX[226,JMC]
MRHUG.QUE[226,JMC]
ASHLEY.LE1[LET,JMC]
74DEC1.AJT[LET,JMC]
WEINER.ME1[LET,JMC]
WEINER.GRP[LET,JMC]
WEINER.ME2[LET,JMC]
SMITH.LE1[LET,JMC]
GAREY.LE1[LET,JMC]
BERG.LE2[LET,JMC]
KOREA.2[S75,JMC]
KOREA.POL[S75,JMC]
ENGINE.LE1[LET,JMC]
RUSSIA.LE1[LET,JMC]
GELFAN.LE1[LET,JMC]
MT.PRO[ 1,JMC]
JUL75.OUT[MSG,JMC]
AUG75.OUT[MSG,JMC]
SEP75.OUT[MSG,JMC]
JAN75.OUT[MSG,JMC]
DEC74.OUT[MSG,JMC]
MAR75.OUT[MSG,JMC]
APR75.OUT[MSG,JMC]
MAY75.OUT[MSG,JMC]
JUN75.OUT[MSG,JMC]
APR75.IN[MSG,JMC]
MAR75.IN[MSG,JMC]
INGERM.LE1[LET,JMC]
FRA[ 1,JMC]
FR2[ 1,JMC]
SQUIBS.PRO[ 1,JMC]
MODEST[S75,JMC]
HOW.ESS[CUR,JMC]
LEADER.ART[CUR,JMC]
LICK.PRE[CUR,JMC]
REPRES.LIC[CUR,JMC]
REPRES.LI2[CUR,JMC]
GOALS.LIC[CUR,JMC]
TWOMOD.ESS[CUR,JMC]
FORMAL.PRO[CUR,JMC]
SALARY.MEM[CUR,JMC]
SCIP[CUR,JMC]
IDEOLO[CUR,JMC]
ECON.NOT[CUR,JMC]
AICIRC.ABS[CUR,JMC]
CPDUST[CUR,JMC]
IDEOLO.ART[CUR,JMC]
APHOR.AI[CUR,JMC]
ECO.ESS[CUR,JMC]
RACKET.ESS[CUR,JMC]
PROPOS.BLA[CUR,JMC]
PHIL[CUR,JMC]
COMMON[CUR,JMC]
MENTAL[CUR,JMC]
NEWS75.MOD[CUR,JMC]
EXEC.SUM[CUR,JMC]
PRODUC.ESS[CUR,JMC]
STANDA.ESS[CUR,JMC]
ARPMTC[CUR,JMC]
IDEOLO.ESS[CUR,JMC]
CHESS1[CUR,JMC]
SOCIAL.DEF[CUR,JMC]
RAMSEY[CUR,JMC]
ARPA75.OUT[MSG,JMC]
1974.IN[MSG,JMC]
JAN75.IN[MSG,JMC]
JUL75.IN[MSG,JMC]
FEB75.IN[MSG,JMC]
AUG75.IN[MSG,JMC]
XGPPUB.1[ESS,JMC]
ADMIT.PUB[CUR,JMC]
KHABAR.AI[S75,JMC]
NEWS75.SUP[ESS,JMC]
NAKATA.LE1[LET,JMC]
LEM.LE1[LET,JMC]
HENDRI.REV[ESS,JMC]
TWOEAS.MEM[258,JMC]
HOMER.LE1[LET,JMC]
REPRES.DOC[ESS,JMC]
REPRES.NOT[ESS,JMC]
REPRES.REP[ESS,JMC]
SCHULT.LE1[LET,JMC]
OPTIM[F75,JMC]
DYSON.LE1[LET,JMC]
RUSSEL.ME1[LET,JMC]
LUMELS.LE1[LET,JMC]
NEWBOR.REV[F75,JMC]
NICK.FIL[F75,JMC]
TASK.TA[F75,JMC]
SEXP[F75,JMC]
AI[F75,JMC]
LATIME.LE1[LET,JMC]
GENERA[F75,JMC]
SANDEW.LE2[LET,JMC]
LISP.MAN[S75,JMC]
DEFINE[F75,JMC]
PHIL.ART[F75,JMC]
BULLET[F75,JMC]
DATA1.204[F75,JMC]
DATA4.204[F75,JMC]
DATA3.204[F75,JMC]
ISHII.LE1[LET,JMC]
ED1.DO[ESS,JMC]
EDH.DO[ESS,JMC]
TEXTOR.LE1[LET,JMC]
OFFICE.PLN[F75,JMC]
REPRES.P75[ 1,JMC]
AIORG.PLN[ 1,JMC]
IJCAI.ENQ[F75,JMC]
ASHENH.LE2[LET,JMC]
IJCAI.DOC[F75,JMC]
ASHENH.LE1[LET,JMC]
LUK.LE1[ 2,JMC]
DCL2.75[LET,JMC]
AAAS.76[ESS,JMC]
AAAS[ESS,JMC]
LUCKHA.LE1[LET,JMC]
SCIENC.LE2[LET,JMC]
HOARE.LE1[LET,JMC]
NILSSO.ME1[LET,JMC]
SCIENC.LE3[LET,JMC]
ABELSO.LE1[LET,JMC]
HJERPP.LE1[LET,JMC]
RELATI.POX[CUR,JMC]
BROWN.LE1[LET,JMC]
MOSES.LE1[LET,JMC]
GILFIL.REV[F75,JMC]
SCOTT.LE1[LET,JMC]
SENSE.AD[LET,JMC]
PR1.DEC[F75,JMC]
AJT.MEM[ESS,JMC]
RAWLS.REV[ESS,JMC]
CYCLOP[F75,JMC]
GINI.LE1[LET,JMC]
SENSE.POS[F75,JMC]
MARTEL.LE1[LET,JMC]
MARTEL.DOC[LET,JMC]
ROTH.LE1[LET,JMC]
FRIED.LE2[LET,JMC]
FRIED.LE1[LET,JMC]
FIXUP.LBK[F75,JMC]
FIX[F75,JMC]
BRINKE.LE1[LET,JMC]
TABLE[F75,JMC]
BLIROB.AX[226,JMC]
TERMPA.206[F75,JMC]
FIXUP2.LBK[F75,JMC]
BLIROB.DOC[226,JMC]
RYLE.REV[F75,JMC]
FIXUP[F75,JMC]
TUNNEY.LE1[LET,JMC]
BLIROB.COM[226,JMC]
NEWS75.PUB[CUR,JMC]
FIXUP2[F75,JMC]
BRINKL.LE1[LET,JMC]
JAF.LE1[LET,JMC]
SENSE.LE1[LET,JMC]
MOTIV.ART[ AI,JMC]
GARDNE.LE2[LET,JMC]
DAILY.ART[F75,JMC]
SENSE.LE2[LET,JMC]
REVAL3.LBK[F75,JMC]
REVAL2.LBK[F75,JMC]
AUTOMA[F75,JMC]
AUTOMA.2[F75,JMC]
COUNTE[F75,JMC]
PR1.AX[F75,JMC]
HOTER[CUR,JMC]
MELTZE.LE[LET,JMC]
HOTER.1[CUR,JMC]
NOV.ME[LET,JMC]
HEAD.LET[LET,JMC]
MACHIN[F75,JMC]
BETHE.LE1[LET,JMC]
SENSE.DAT[F75,JMC]
GOLDMA.LE1[ 2,JMC]
BETHE.LE2[LET,JMC]
FINITI[F75,JMC]
SOULE.LE1[LET,JMC]
SCIENT.LE1[LET,JMC]
THESIS[F75,JMC]
MINIMA[F75,JMC]
FIB[F75,JMC]
DEC75.IN[LET,JMC]
FIELDS.ME1[LET,JMC]
BLEDSO.LE1[LET,JMC]
BLEDSO.DOC[LET,JMC]
YOST.LE1[LET,JMC]
RAPHAE.LE1[LET,JMC]
GARDNE.LE1[LET,JMC]
GABOR.LE1[LET,JMC]
RHODES.LE1[LET,JMC]
CHERN.LE1[LET,JMC]
FIELDS.SUP[LET,JMC]
NEWYOR.LE1[LET,JMC]
KAHN.LE1[LET,JMC]
LISP.INT[F75,JMC]
BLOCKS.226[F75,JMC]
NOTES.226[F75,JMC]
TAUT.PRF[F75,JMC]
UTILI.AIL[F75,JMC]
MOSSIG.LE1[LET,JMC]
PET.LIT[LIT,JMC]
TOLEDO.LE1[LET,JMC]
CBCL[F75,JMC]
SET.AX[F75,JMC]
SET[F75,JMC]
SENSE.LE3[LET,JMC]
FILMAN.RE2[LET,JMC]
CONS.AX[226,JMC]
SMULLY[226,JMC]
GIL1[ 2,JMC]
KNOPOF.LE1[LET,JMC]
YAMADA.LE1[LET,JMC]
∂25-Oct-77 2206 MRC multiplexed connections
To: LES, JMC
I have reinstated a byte field (8. bits) in the DIALnet packet header for
multiplexed connections. It is not documented as such; only that it is
reserved for future use and must be sent as 000 by the sender and that the
receiver should ignore it. I got objections for other hackers who convinced
me that it would be a bad idea not to allow for it (although it was acceptable
for it not to be available in the first incantation).
The scheme will be much simpler than the initially proposed one. Instead of
DCP involvement and all that, to have a multiplexed connection the sender
simply puts a value other than 000 in that field. Receivers who do not
support multiplexed connections will see it as an RPC when a connection
exists and barf on it in the right way.
So if anybody wants it we will have it. I think that if we get a dedicated
link to LOTS for TELNETting we might want this.
∂25-Oct-77 2310 MRC modems
To: JMC, LES
So what is the state of the world wrt modems? I think the host-to-host
protocols are in a good shape now.
∂26-Oct-77 0015 LES
CC: JMC
∂25-Oct-77 2357 LES Multiplexed links
To: MRC
A dedicated link to LOTS or anywhere else is not part of Dialnet.
Dialnet, as its name implies, uses dialup lines. I do not understand
why the "other hackers" and you want to try to duplicate the capabilities
of other kinds of communication system. When the time comes to invent
other protocols for other purposes, that's no big deal.
If it makes you feel better to leave 8 bits unused, I do not object for
now; but if I hear you call it a "multiplex field" or something like
that, I'll personally bite every bit.
∂26-Oct-77 0406 MRC Host-host protocols
To: JMC, LES
CC: PAT
I FINALLY have them in a coherant state again, and think they are a lot
better. Besides some things like the time out times (which were pulled
out of the hat randomly) and a few other picky details, I think I am at
more or less what it is going to be like.
Patte can XGP (using /NOHEADING of course!) the file HSTHST.PRO[DLN,MRC]
to send to the Bell Labs people whenever she wants to. Maybe you want
to make last-minute "ripping to shreads" on it first though?
Sleepily (I've been up for a LONG time...),
Mark
∂26-Oct-77 1103 TOB INTERVIEW
To: JMC, LES
SCOTT ROTH FROM CALTECH IS HERE NOW. I HOPE
THAT YOU CAN TALK WITH HIM TODAY.
TOM
∂26-Oct-77 1652 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 26 OCT 1977 1950-EDT
From: CARL at MIT-AI (Carl Hewitt)
To: CARL at MIT-AI, jmc at SU-AI
Ok. Did you get the copy of the paper with my preliminary comments on it?
Cheers,
No, I didn't see the paper. Was it a message or did you put it in
a file?
∂26-Oct-77 2313 FTP:Feigenbaum at SUMEX-AIM dinner with the Simons
Date: 26 OCT 1977 2312-PDT
From: Feigenbaum at SUMEX-AIM
Subject: dinner with the Simons
To: jmc at SAIL
John, can you and Vera join us and the Simons for dinner next Thursday night?
As you know, Herb is at Stanford for lectures in our department (and other
places) and we're going to have a dinner for Herb and Dot on thursday night.
I hope Josh and his wife will be able to join us too. Perhaps others.
Let me know if you can or can not.
Best,
Ed
-------
Ed, Vera and I will be happy to join you for dinner next Thursday.
Thank you very much.
∂27-Oct-77 1320 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 27 OCT 1977 1619-EDT
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
John,
The version of your paper with my comments interspersed is
LISP.COM[F77,JMC]. Good luck on your efforts with the other members of
the committee to get an invitation for Stoyan.
Sincerely,
Carl
∂27-Oct-77 1437 FTP:Bob Sproull at CMU-10A DialNet comments
Date: 27 Oct 1977 1733-EDT
From: Bob Sproull at CMU-10A
Subject: DialNet comments
To: mrc@su-ai, les@su-ai, jmc@su-ai
Sender: BOB.SPROULL at CMU-10A
Message-ID: [CMU-10A] 27 Oct 1977 17:33:51 Bob Sproull
Sorry that I have not come through with DialNet comments earlier, but
here they are. Rather than argue with items directly, I have chosen
instead to offer a counter-offer, and see what you think.
1. (In the file Dialne.Mem, the NSF proposal). It seems to me that
one implication of the "phone number" view of the world is that the
naming scheme for "sites" may often use literal numbers. Thus, in
the example of smith returning a message (page 4) that includes a
pointer to DAVE@UTEX-CHEM3, it would probably have been better
practice to couch the pointer in fully literal form such as
DAVE@512-471-3222 or whatever the number is. Thus, it doesn't depend
on the recipient's having the proper address.
2. It seems to me that DialNet should primarily be kept EXTREMELY
simple so that home terminals and modest computers can implement it,
and also so that ordinary mortals reading documentation and trying
implementations encounter as few surprises as possible.
To that end, it seems to me that an individual circuit (i.e., the
connection made by one computer dialing another) should NOT be
further packet-multiplexed. That is, a computer should call another,
transmit a single file, and hang up. Or, if several files are to be
transmitted, it calls up, transmits file 1, transmits file 2, and
then hangs up.
The whole point is to let the telephone equipment do the switching.
Someday, DialNet may even use communication services that are
actually implemented with packet switching, or whatever. But the
separate communicating computers need not be concerned with that --
it's a communications issue.
Now I realize that this proposal screws up two things: (1)
TELNET-like use of DialNet by multiple users over one communications
circuit, and consequently (2) your own desires to help SU-AI and LOTS
communication. I guess I believe that remote login is worth a
separate connection (particularly at the speeds we are talking
about), and that little will be gained by protocol to multiplex the
connection in a fine-grained way.
So my model is best thought of as a file-transfer facility. One
computer calls another, and sequentially transmits each file it has
for the partner, and hangs up. Very simple.
3. Starting the connection. I think you should think a little about
automatic speed recognition preceeding the transmission, as there are
pretty good ways of doing this, and it avoids having to keep an
up-to-date directory of everyone's modem speeds.
Then, it seems to me you ought to make provision for detecting 2
modes of connection: from another computer (C) or from a person (P)
using a terminal.
The point of the person-mode is that some computers may be willing to
implement an interactive system for people who own only terminals to
enter files or mail for users at the site, or for forwarding
elsewhere. Individual sites can offer different interactive schemes
for prompting for messages, editing, limiting time "logged in", etc.
DialNet doesn't really have to specify much, except how an answered
phone call can be put in this "mode." Clearly, a site does not have
to implement such P facilities at all.
So a connection might start with a speed-recognition character, or
perhaps some simple exchange to be sure everything is agreed
(remember, a person has to be able to do it). Then comes a character
to set the proper "mode". (All of this is in terms of asynchronous
communications; for synchronous stuff, you can assume it's not a P,
and may even want to assume you know the speeds.)
4. Now let's assume we're in C mode, and want to transmit some stuff.
First, you need a way of reliably sending a "chunk" (or packet) of
information, and getting some kind of a response. I suggest
something simple: herald character, followed by 3-char count,
followed by that many characters, followed by check sum. Might use
two different heralds, one of which asks for a response. I don't
think the details of this "reliable-chunk" mechanism are particularly
important, but they should be simple. Note that addressing, and flow
control are simply not needed. It might be nice, however, to be able
to have two flavors of chunk: COMMAND and DATA.
Assuming we can transmit chunks, we can (1) define protocol schemes
as COMMAND chunk exchanges, and (2) implement streams of data as
simply a succession of DATA chunks.
Now let's look at a file transfer transaction. We might like to have
three phases: (1) send file name, path, password, account etc. as
free text in a COMMAND chunk, and get some sort of response; (2) send
the file as a bunch of DATA chunks, provided the response to (1) was
OK; (3) ask, via some COMMAND exchanges, whether the entire
transaction was OK. At any time during these, the receiver might send
a COMMAND chunk that aborts things (out of file space, etc.)
The same scenario works for mail message transfer. The initial phase
simply specifies a mail message comming. The second phase is the
text (including all the header fields, etc.). The final phase
verifies that the mail was received (e.g., no such local user, unable
to forward, etc.) A "smart" mail system could parse header fields
during phase 2, as the message arrives, and issue an early abort if
it is going to refuse the mail.
Because COMMAND exchanges are relatively rare, they might as well be
in some simple free-text form, e.g.
COMMAND: File-transfer, FileName=<sproull>foo.dat, USER=Sproull, Password=eighty
or
COMMAND: Abort, Comment=No such local user
These will certainly be easy to understand, and relatively simple to
parse (use very simple rules: phrases are separated by commas, and
are of the form keyword or keyword=string).
5. Presentation. I believe it is very important to style the
presentation of your protocols so that the simple things (probably,
in the case of DialNet, a simple text message) are kept simple, and
are described in a simple way. If there are 40 million options for
doing other things, describe them separately. We made this mistake
in the NGP: the mandatory parts of the protocol are VERY simple, but
the simplicity is completely obscured by all the crap in the document
describing the protocol.
Please take all these comments with a grain of salt. I am NOT trying
to design your system, but merely offering the observation that
YOU'VE GOT TO KEEP IT SIMPLE. My only objective in offering the
alternative (arm-chair) design is to try to make that point.
-------
∂27-Oct-77 2019 RAK
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
REMINDER!
VERIFICATION GROUP SEMINAR TUESDAY 1 NOVEMBER
PLACE: ERL 237
TIME: 2.00 pm.
Tuesday, November 1
TITLE: EFFIGY and Symbolic Execution
*********************************************************
SPEAKER: JIM KING
Our particular notion of symbolic execution as implemented in
the EFFIGY System will be explained. Symbolic execution will be
promoted as a useful program analysis tool, with examples taken from
our EFFIGY experiences. EFFIGY now has four "modes" of program execution
including: interactive execution, testing (automatic tree walker),
test coverage analysis, and correctness proof. The first two may be
used on programs having assertions in which case the assertions
are checked in each instance they are encountered.
A cute (ED NOTE: CUTE?!?) way of providing a lemma capability for
subprograms which we call "abbreviated procedures" will be explained.
As a grand finale for those of you who don't already know we will explain
the derivation of the name EFFIGY.
∂27-Oct-77 2032 MRC via AMET Sproull's comments
To: LES, JMC
CC: Spoull at CMU-10A
On a single reading (at 30CPS on my glass TTY--I'm at home now), many of
his comments were applicable to the high-level protocols like FTP, etc.
but appeared to be even hairier than necessary. Others seemed to be
more appropriate to something like PCnet than to a communication protocol
like DIALnet. I do agree that switching from site to site to site is
a loss (although instead of forbidding it I will just not implement it
in any of the official protocols; people who want forwarding can design
their own ways of doing things).
Bob, I'm afraid you haven't seen the new set of site to site low level
protocols. Yes, it is packet oriented, and uses a CRC checksum.
Read the file HSTHST.PRO[DLN,MRC] at SAIL. You will have character set
problems which I don't think TYPE A FTP'ing will help you with (I think
TYPE A only converts between SAIL and normal ASCII, not SAIL and MIT ASCII
which you'll probably need-- I use several special graphics as this
is intended to be an XGP file). So FTP it in image mode, then print it
using SAIL's FIX25 font. It exists in MIT format (which I think is
compatable with CMU format) as MRC;FIX25 KST on MIT-AI. I have asked Moon
and Stallman for comments on the current low level protocols already;
they have helped me with protocol type documents before.
Regards,
Mark
[PS - Please don't send me right-justified mail. I do it for documents only
to make the readers happy and not get silly comments from APL users about
this random (usually undebugged) right justification function they have which
proves APL is better than anything else......... Anyway, I agree with the
people who say it looks ugly. Thanks. -- Haldir]
∂28-Oct-77 0836 BPM New ARPA Director?
To: JMC, LES, CCG, TW, DCL, TOB, ZM
Rumor has it that George Heilmeier will be leaving ARPA at the end of
November. Don't know where he is going.
Heilmeier will be replaced by someone named FOSSUM, who is currently the
director of the Naval Postgraduate School.
∂28-Oct-77 1016 FTP:Feigenbaum at SUMEX-AIM dinner and discussions with Col. Russell
Date: 28 OCT 1977 1017-PDT
From: Feigenbaum at SUMEX-AIM
Subject: dinner and discussions with Col. Russell
To: jmc at SU-AI
John, can you join Col. Russell and me for dinner and discussions
at the faculty club on Nov. 7 (Monday), at 6pm? This is the postponed
meeting.
Ed
-------
Ed, Yes, dinner at the Faculty club will be fine. - John
∂28-Oct-77 1311 FTP:Feigenbaum at SUMEX-AIM information update
Date: 28 OCT 1977 1312-PDT
From: Feigenbaum at SUMEX-AIM
Subject: information update
To: jmc at SAIL
Heilmeier is going to TI to be vp for research.
The new director is Dean of Research at the Postgraduate school.
Ed
-------
∂28-Oct-77 1451 TED
To: PMF, JMC
I have turned off the reveiver board for line 15. The Imlac
is apparently sending garbage to the system.
∂28-Oct-77 1902 PMF
Sat.
I'll be around here or there, so whenever it's convenient.
∂29-Oct-77 0104 MRC Maximum packet size
To: Moon at MIT-MC
CC: LES, JMC
I have reduced the size field of the packet header to one byte. After talking
with several people, I realized that 255. bytes was an ample maximum data area
size (ie, 2040. bits). Hence the maximum packet size is 263. bytes and the
minimum packet size is 8. bytes.
Thanks for pointing out this problem.
∂30-Oct-77 1313 JMB colloquium
November 22 or November 29th are available. Take your
pick. Note that the 22nd is Tues before Thanksgiving, and
possibly not the best time to give a talk.
....Jeff
∂30-Oct-77 1341 JMB colloquium (date confirmation)
I have scheduled you to give a talk on Nov. 22 at the usual
time of 4:15 PM in 111 Polya. When that date approaches, I
will need to know what equipment you will need for the talk.
....Jeff
I will need a transparency projector.
∂30-Oct-77 1850 MRC DIALnet mail formats
To: Header-People at MIT-MC, JMC
To those who got part of this message before, I apologize. SAIL's
mail user program cleverly uses MAIL instead of MLFL and a line with
only a dot in it terminates the message.
With the completion of the first version of the DIALnet host-host
protocols, my attention has returned to the subject of DIALnet mail.
I solicit your suggestions for the design of a mail protocol. As of
this writing, there are two theories as to how it should be done. In
either case, the ARPAnet way of doing things (as a command to the
file transfer protocol with the information in a mail header) has
been rejected.
My concern is to have a single protocol which will be satisfactory
for both "smart" and "dumb" mailing systems. A "dumb" mailing system
is a bare bones system which "does the job". A "smart" mailing
system has extra hairy features. Every mail system has to be able to
be "dumb", but if both are "smart" about something they can use it.
The first theory makes MAIL much like the ARPAnet FTP protocol. A
sample command would be something like this:
MAIL:
TO : MRC
FROM: MRC @ (415)-497-5505
MSG :
This is a test.
.
END :
The server reads these commands (which are canonical card-image type
things) and delivers the message with whatever header is desired. The
only thing required is the TO entry. Everything else is optional!
The only thing that is attractive about this design though is that
it could be written in any sort of bad environment; it is a trivial
FORTRAN program for example.
The second theory (and the one that is getting more attention around
here) is a LISP-like mail format. The advantages to using a LISP-like
syntax are numerous, since it allows not only the removal of all sorts
of quoting and ambiguity problems, but it also is easy to parse S-
expressions. That test message above would look like:
(MAIL (TO MRC) (FROM MRC (PHONE (415)-497-5505)) (MSG (This is a test.)))
We are wondering if any site would have difficulty in writing software
that could parse S-expressions, and if so, we would like a detailed
explanation of why it would be difficult.
Please note that this is not a protocol specification. There are still
many other things that have yet to be decided upon. It's only to express
the general idea.
Mark
∂31-Oct-77 2217 LES PDP-1
DBA would like to know where the PDP-1 went in India; he apparently plans
a trip there and is looking for places to visit.
The PDP-1 went to the Indian Institute of Technology in Kanpur.
∂31-Oct-77 2318 MRC
∂31-Oct-77 1153 FTP:MOON at MIT-MC (David A. Moon) Dialnet mail protocol
Don't dismiss the Arpanet mail protocol too lightly. There are some
good reasons for why it is the way it is, which are distinct from
the reasons it loses.
The reason "TO:" is a command to ftp, while everything else is text
in the message, is that "TO:" is the only thing requiring interaction,
since the server has to say whether it has heard of the person in
question and knows how to send mail to her. "TO:" has to ALSO appear
in the "header", because the recipient wants to have a way to
find out who else the message was sent to, and some of those people
may not even be at the same host, so their "TO:" commands would not
have been seen by the ftp at this host.
The problem with the Arpanet mail protocol is that it is difficult and
complicated to do anything with the "header" information, other than
print it out, because it is ill-defined (which RFC 733 should fix) and
not highly-enough structured, which RFC 733 does not seem to help with.
It sounds like what you're looking for is a scheme where the "header"
information (i.e. all the auxiliary information which is transmitted to
make more useful processing of the message possible, but is not the
body of the text) is kept strictly separate from the message text, in
an easily-processed form. (This does not imply that it is best to
make it "commands" in an ftp-like underlying protocol.) One problem
with this is that you are immediately committing all users of Dialnet
to a considerably hairier mail program than most Arpanet sites have
now; when presenting the message it has to take those fields that the
user always wants to see, and present them in a nicer way than their
presumably easier to process for programs form, and it has to have
commands to get out the information you want to see, but only
sometimes.
The problem with transmitting the information in Lisp S-expression
form is not parsing it, that is obviously trivial (although there
are a number of lurking bugs in your example, e.g. the parentheses
in the telephone number). The problem is what do you parse it into?
(And possibly, why didn't you just transmit the information in that
form in the first place?) And you are certainly not going to show
the S-expressions to the user. No one can accuse me of being opposed
to Lisp, in its [rather large but not all-encompassing] place,
but this is not a reasonable format for people to look at for mail.
The advantages of S-expressions are that they are a fully-general
way to encode structure (except for circular and re-entrant forms),
and that they strongly discourage the use of lexical syntax (all
the colons and angle brackets and @-signs and " at "-signs of 733).
How much structure are you planning to need, anyway? How hairy
are you trying to be?
I'm not saying that transmitting the "header" information in S-expression
form is a bad idea, but I am saying that choosing that way will
commit you to a great deal of thought about how it needs to work,
and will commit the users and implementors to hairier mail programs
then they may want. Consider how huge and bloated this could look
from the standpoint of pcnet and its microcomputers, for instance.
∂01-Nov-77 0047 MRC Host-host protocol memo
I hope Patte hasn't send the protocol document off yet. There is an error
in the bibliography.
∂01-Nov-77 0706 MRC Jules Gilbert
To: LES
CC: JMC, Ellen at MIT-MC, JPG at MIT-MC
I understand that Jules Gilbert is trying to get an account here. I have
heard some things about him which would strongly suggest that he shouldn't
have an account. He's been going all around the ARPAnet trying to get
accounts, and is evidently quite obnoxious and has been giving MIT a lot of
trouble.
Ellen%MC or JPG%MC could supply more details; I don't really want to know!
∂01-Nov-77 1131 FTP:Feigenbaum at SUMEX-AIM more on dinner with the Simons thursday
Date: 1 NOV 1977 1129-PST
From: Feigenbaum at SUMEX-AIM
Subject: more on dinner with the Simons thursday
To: jmc at SAIL
The Feigenbaum-Nii dinner for Herb and Dorthea Simon will
be at Caleta restaurant in Menlo Park at 7:30PM on Thursday.
However, we will be assembling and having cocktails at our
house beginning about 6:30, if you can make it. Then we can
all go over to Menlo Park caravan-style. If you arrive at our
house and we're gone, proceed directly to the restaurant (north
of Santa Cruz Ave. on Crane).
-------
We'll be there about 6:30, thanks.
∂02-Nov-77 1616 JP MACLSP meta-D directory feature
To: MACLSP.DIS[AID,RPG]:;
Subsribers of the HELP autodef package:
A new feature has been added to SAIL MACLSP to enable obtaining fast
directory listing using RPG's DIRECT fn. It permits use of >,#, and * as
wildcards. To access the package do when talking to MACLSP
βD <filespec> ;;; note: D not d!
where filespec is of the form filnam.ext[p,pn] and where ext,p,pn and the
syntactic delimiters can be omitted in the obvious cases. * wildcards are
allowed for for filnam and ext. If p or p,pn are omitted, they are
obtained from your current crunit device.
Ext can also be > and #. > obtains the largest numbered version, and # denotes
all numbered versions.
Ex:
*.#[lu,ser ;all files with numeric extension in [lu,ser
*.>[foo, ;the file with largest numeric ext in [foo,
*. ;all files w/o ext in crunit dir
...etc...
NOTE: No wildcards allowed in PPN!
∂02-Nov-77 1645 FTP:Taynai at SUMEX-AIM Course Evaluation
Date: 2 NOV 1977 1642-PST
From: Taynai at SUMEX-AIM
Subject: Course Evaluation
To: Kay at XEROX-PARC, TOB at SAIL, JMC at SAIL, Wiederhold,
To: Polak at SAIL
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 November 2, 1977
C00007 ENDMK
C⊗;
! November 2, 1977
TO: Instructors of Computer Science Courses
FROM: Course Evaluation Committee
SUBJECT: Autumn Quarter Course Evaluation
This quarter the Sub-Committee on the Evaluation and Improvement of
Teaching (SCEIT) is testing an experimental course evaluation form
designed to supersede the old ASSU Course Guide questionnaire. They
have asked various faculty members to use the new questionnaire for
evaluating their courses; you may have been one of those contacted.
As you probably know, the Computer Science department has for some
time now supervised a course evaluation procedure independent of the
ASSU. Some questions have been raised as to the interaction between
the departmental evaluation committee and the experimental procedure.
We have discussed the matter with Greg Larson of the ASSU Council of
Presidents, and were given the impression that, as we already have a
viable evaluation process, we would not be required to make any major
modifications to it. Since performing two evaluations generally takes
up too much class time, it was decided that the evaluation of computer
science courses would continue to be done by our committee.
Apparently this decision was not suitably disseminated to all members
of the SCEIT.
In our opinion the departmental evaluation process provides better
information than that proposed by the SCEIT. Therefore, if you do not
want to take the time to do two separate course evaluations, we
encourage you to use the CS questionnaires. (We will be sending you
the usual memo regarding course evalution in about a week.) As
always, we will be happy to respond for you to the SCEIT request for
evaluation, and will make our results available to the ASSU Course
Guide, the SCEIT, and any other interested University organizations.
!
It would be interesting to compare the results from the CS and SCEIT
questionnaires. Therefore, if you feel you can that you can spare the
class time, you might wish to perform both evaluations. If you do so,
we ask that you do them on separate days, so that the students will
not feel overly rushed while filling out either form. Our experience
has been that, when ASSU and CS questionnaires are distributed
simultaneously, most students give abnormally brief responses to both.
If you have any questions or comments about these issues or about
course evaluation in general, please call John Gilbert (x7-1658) or
Don Woods (x7-4425).
Sincerely,
The Course Evaluation Committee
cc: Robert Calfee (SCEIT)
David Parker (ASSU)
Sally Mahoney
Greg Larson
-------
∂02-Nov-77 2157 FTP:Feigenbaum at SUMEX-AIM Feigenbaum's electric calendar
Date: 2 NOV 1977 2155-PST
From: Feigenbaum at SUMEX-AIM
Subject: Feigenbaum's electric calendar
To: jmc at SAIL
Feigenbaum's electric calendar has just recorded a party at JMC's house
on Nov. 19.
-------
∂03-Nov-77 0402 LES Dialnet
To: Sproull at CMU-10A
CC: MRC, JMC
Please don't give up so easily.
I believe that many of the issues you mentioned in you message-before-last
have not been faced yet in the Dialnet design. MRC is still working on
the low-level protocols, whose only function is to reliably move packets
of bits from a process in one machine to one in another. These processes
will implement the higher level protocols that handle Mail, FTP, remote
login, etc.
I agree with your remark about multiple connections; that stuff has all
been flushed in the current protocol. On the other hand I don't
understand how you can avoid sending a process ID; that is how we plan to
identify which of the higher-level protocols is being invoked.
The following remarks are keyed to the numbered paragraphs of your 27 October
message.
1. Here you are talking about the user-program interface, which is not
properly a part of Dialnet. I would like to see some standardization
of keyboard commands, but this is not essential. Our example using a
site name was meant to suggest that the computer could provide telephone
number look-up services; literal numbers would certainly be permitted.
2. I agree fully with these remarks. MRC is not totally convinced;
he still has an unassigned one-byte field in each packet that could
be used to specify a link number. Over my dead body.
3. My impression is that automatic speed recognition equipment currently
works in the 300 baud and below range and that this is not likely to change.
We are planning to start with 1200/1200 baud modems and, when faster
rates become available at reasonable price, use them. For those who
wish to use adaptive lower-speed equipment, I see no major problem
in arranging to send the right synchronization sequence.
I don't quite understand your remarks about supporting a person with
a terminal. If it is a fairly smart terminal, then Dialnet could indeed
be used. If it is a rather dumb terminal, then it should connect directly
to the exec of the host computer. Now if someone wrote a very clever
program for listening to the modems, it might permit their use in either
way--i.e. either as a normal terminal port or as a Dialnet port (but not
both at the same time). We currently have no plans to try this.
4. MRC's current plans for the low-level protocol are given in
HSTHST.PRO[DLN,MRC]. It would be best if we could argue about needless
complexity or oversimplification in terms of concrete proposals such as
this.
For the higher-level message structures, JMC proposes Lisp-like S-expressions
A discussion of this idea between MRC and Moon @MIT-MC is attached.
This scheme is similar to yours in that it facilitates parsing.
5. I agree completely. So does MRC.
Cheers,
Les
----------------
∂30-Oct-77 1918 MRC DIALnet mail formats
With the completion of the first version of the DIALnet host-host
protocols, my attention has returned to the subject of DIALnet mail.
I solicit your suggestions for the design of a mail protocol. As of this
writing, there are two theories as to how it should be done. In either
case, the ARPAnet way of doing things (as a command to the file transfer
protocol with the information in a mail header) has been rejected.
My concern is to have a single protocol which will be satisfactory for
both "smart" and "dumb" mailing systems. A "dumb" mailing system is a
bare bones system which "does the job". A "smart" mailing system has
extra hairy features. Every mail system has to be able to be "dumb", but
if both are "smart" about something they can use it.
The first theory makes MAIL much like the ARPAnet FTP protocol. A sample
command would be something like this:
MAIL:
TO : MRC
FROM: MRC @ (415)-497-5505
MSG :
This is a test.
.
END :
The server reads these commands (which are canonical card-image type
things) and delivers the message with whatever header is desired. The
only thing required is the TO entry. Everything else is optional! The
only thing that is attractive about this design though is that it could be
written in any sort of bad environment; it is a trivial FORTRAN program
for example.
The second theory (and the one that is getting more attention around here)
is a LISP-like mail format. The advantages to using a LISP-like syntax
are numerous, since it allows not only the removal of all sorts of quoting
and ambiguity problems, but it also is easy to parse S- expressions. That
test message above would look like:
(MAIL (TO MRC) (FROM MRC (PHONE (415)-497-5505)) (MSG (This is a test.)))
We are wondering if any site would have difficulty in writing software
that could parse S-expressions, and if so, we would like a detailed
explanation of why it would be difficult.
Please note that this is not a protocol specification. There are still
many other things that have yet to be decided upon. It's only to express
the general idea.
∂31-Oct-77 1153 MOON at MIT-MC Dialnet mail protocol
Don't dismiss the Arpanet mail protocol too lightly. There are some good
reasons for why it is the way it is, which are distinct from the reasons
it loses.
The reason "TO:" is a command to ftp, while everything else is text in the
message, is that "TO:" is the only thing requiring interaction, since the
server has to say whether it has heard of the person in question and knows
how to send mail to her. "TO:" has to ALSO appear in the "header",
because the recipient wants to have a way to find out who else the message
was sent to, and some of those people may not even be at the same host, so
their "TO:" commands would not have been seen by the ftp at this host.
The problem with the Arpanet mail protocol is that it is difficult and
complicated to do anything with the "header" information, other than print
it out, because it is ill-defined (which RFC 733 should fix) and not
highly-enough structured, which RFC 733 does not seem to help with. It
sounds like what you're looking for is a scheme where the "header"
information (i.e. all the auxiliary information which is transmitted to
make more useful processing of the message possible, but is not the body
of the text) is kept strictly separate from the message text, in an
easily-processed form. (This does not imply that it is best to make it
"commands" in an ftp-like underlying protocol.) One problem with this is
that you are immediately committing all users of Dialnet to a considerably
hairier mail program than most Arpanet sites have now; when presenting the
message it has to take those fields that the user always wants to see, and
present them in a nicer way than their presumably easier to process for
programs form, and it has to have commands to get out the information you
want to see, but only sometimes.
The problem with transmitting the information in Lisp S-expression form is
not parsing it, that is obviously trivial (although there are a number of
lurking bugs in your example, e.g. the parentheses in the telephone
number). The problem is what do you parse it into? (And possibly, why
didn't you just transmit the information in that form in the first place?)
And you are certainly not going to show the S-expressions to the user. No
one can accuse me of being opposed to Lisp, in its [rather large but not
all-encompassing] place, but this is not a reasonable format for people to
look at for mail.
The advantages of S-expressions are that they are a fully-general way to
encode structure (except for circular and re-entrant forms), and that they
strongly discourage the use of lexical syntax (all the colons and angle
brackets and @-signs and " at "-signs of 733). How much structure are you
planning to need, anyway? How hairy are you trying to be?
I'm not saying that transmitting the "header" information in S-expression
form is a bad idea, but I am saying that choosing that way will commit you
to a great deal of thought about how it needs to work, and will commit the
users and implementors to hairier mail programs then they may want.
Consider how huge and bloated this could look from the standpoint of pcnet
and its microcomputers, for instance.
∂03-Nov-77 1057 RLD
∂02-Nov-77 1508 JMC debate
I understand that you are one of the movers behind the anti-nuclear
extravaganza of the next few weeks. I would like to challenge any
of your tigers, i.e. Ellsberg, Lovins, or Commoner in that order of
preference to debate the whether the nuclear energy program should
be continued. Would you transmit the challenge, made in the name
of SENSE (Scientists for Enlightenment on Nuclear Sources of Energy)
and let me know if any of them deign to accept it?
REPLY:
Ellsberg (who will speak on nuclear weapons, not power) and Commoner
are heavily scheduled for teachins and will each be here only the one night.
Lovins, on the other hand, might be available later in November. I would be
quite interested in seeing a debate between you and Lovins. Would SENSE be
willing to help out with the publicity and expense (room rentals, etc.) for
such an event? I will relay your challenge to him.
The evening events are set up as panels. On the nuclear energy night
(Thurs., Nov. 10) Commoner and Lovins will each speak for half an hour, and then
will field questions for the rest of the evening. Why don't you and your crew come
up with some good questions to see if they really know what they are talking about
or are full of hot air?
If a debate is arranged, we will certainly help with publicity, etc.
A distinguished speaker vs. random audience questioners is not ideal
from a point of view opposed to that of the speaker, but some of
us will probably show up anyway.
∂03-Nov-77 1123 PMF
I have been a LLL, and so have heard nothing. I asked Ted
to talk to them, but maybe they didn't do anything.
∂03-Nov-77 1401 LES
CC: JMC, JBR
∂03-Nov-77 1134 RPG S1 operating system proposal
Thanks for pointing out the S1 document. The situation is:
the impression derived from the system meeting is that the monitor would
soon go into limbo in a non-paging state, to remain thus until the lab
is given an S1 with super-monitor (approx. 3 yrs hence). During that time
some initiate would be hired to ponder the mysteries of the system for
the people who use the lab facilities for day to day research. Fortunately
most people doing serious AI programming use facilities elsewhere (eg.
PSI group - RPG, TW's group), so this doesn't effect them that much.
However, other people (also doing serious AI progamming [eg. Luckham,
Binford...]) do use the lab facilities, and there is a serious computational
drawback associated with the lab monitor (program size mainly). These people,
which includes me, fear that their needs may be overlooked while the lab
embarks on a fun (and profitable) venture.
Making the S1 operating system project a non-issue until the
lab has decided interest (at which point it's a non-issue since it's
been already decided?) seems to ignore the fact that others besides
LES, JMC, JBR ... have an interest in the matter.
Probably I don't understand the real issues at hand, and perhaps the
real plan is to get the lab system in spiffy condition before work on the S1
proceeds, and ...; however, could you comment on this?
-rpg-
∂04-Nov-77 1513 DCL
BY THE WAY, I'VE NO OBJECTION TO YOUR BEING PI ON THESE PROPOSALS
As you see from Lieberman's letter, that may no longer suffice.
∂05-Nov-77 0101 JMB Future Intel Processors
I got some clarification on the address space of the future
Intel processors tonight (from Zilog). Apparently
Intel will announce a 16 bit processor with a 20 bit address spa ce
virtually immediately (next week???). This machine is reputed not
to be too fast, perhaps a 5 megahertz clock.
There is also a 32 bit address space machine on the horizon, perhaps to
be announced in late 1978 or early 1979. This machine is reputed to
be quite fast. The Intel strategy seems to be: we are the biggy, wait
for our super processor "soon to come". Meanwhile, the Zilog
people are going to beat them out with the large (32 bit) address
space machine.
....Jeff
Thanks for the information. I would be grateful for any more that
turns up. - John
∂06-Nov-77 1503 RPG New features.
To: MACLSP.DIS[AID,RPG]:;
There are two new features in maclisp which are callable
after (help) is performed.
1. (dir) returns a list of (filename <ext>) for your aliased ppn
2. (dir foo) returns a list of files for foo,pn
3. (dir foo bar) returns a list of files for foo,bar
4. (directory 'foo 'bar) returns a list of files for foo,bar
5. (dir /1 /1) returns a list of all known ppn's on the system (takes
a LONG time.
6. (esci-enb) enables [esc]i interrupt for the purpose of interrupting
running jobs. [esc]i<x> is equivalent to <call> reenter <x>,
but only works well when NOT in a read (i.e. will attempt
to complete the read first).
-rpg-
∂06-Nov-77 1909 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 6 NOV 1977 2050-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
Hello!
The world seems to be waiting for Tom Cheatham to communicate with you
about Stoyan. Jean seems to still have her heels dug in. Barbara is symphathetic.
Did you get my comments on your paper. I stored them on the file you suggested
in [F77,JMC]. Jean would like to see the draft of the paper as soon as you
have it in reasonable shape.
Let me know if there is anything more that I can do for Stoyan,
Carl
Thanks for the comments on my paper. I have started to tinker with it,
but I guess I won't get back to it soon. I suppose that I have met the
request for a draft by Nov. 1. As for Stoyan, I have run out of energy,
and, if Jean can't be persuaded to do anything more decent than the
letter Barbara mentioned in an earlier message, that will have to do.
I haven't heard from Cheatham since an initial phone conversation in
which he said he would do what he could; have you? I sent Barbara a
message today saying that she should ask Jean to send the letter she
sent me a draft of. I hope she is in town.
∂06-Nov-77 1946 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 6 NOV 1977 2246-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
Jean would like to see a copy of the paper. I would pub and
xgp it here if I could but our fonts are named differently and
I don't have your pub init file. So could you please pub the
file and send Jean an xgp copy marked as an initial draft.
Barbara seems to think that Tom is not overly enthusiastic about
Stoyan and so may be dragging his heels a little. (this may be a complete
understanding but is the current rumor).
So I think that the best bet may be as you suggest and get Jean to
send the current letter with hopefully a stronger letter when
the committee meets.
Sincerely,
Carl
OK, let's do it.
∂07-Nov-77 0822 FTP:Feigenbaum at SUMEX-AIM reminder re russell tonight
Date: 7 NOV 1977 0821-PST
From: Feigenbaum at SUMEX-AIM
Subject: reminder re russell tonight
To: jmc at SAIL
diner with col .russell at 6pm at the faculty club tonight (Monday).
-------
I'll be there.
∂07-Nov-77 1115 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR TUESDAY 7 NOVEMBER
There will be no seminar this week. Next seminar is next week, Tueasday
Nov. 15th. Jack Shwartz will talk the following week, Nov 22nd.
∂07-Nov-77 1434 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 7 NOV 1977 1733-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
We need to come up with the name of another discussant besides Stoyan;
the names of Peter Deutch and Paul Abrahams have been mentioned. Do you
have any other suggestions and/or preferences?
Sincerely,
Carl
Either is fine with me. One might also consider Raphael or Bobrow
or Steve Russell.
∂07-Nov-77 2319 CLT 206
Do you have the midterms for people in TVland? If so, please bring them tomorrow
and I will get them sent out.
I have some midterms that weren't collected, and I'll bring them.
∂08-Nov-77 0741 FTP:LISKOV at MIT-DMS Stoyan
Date: 8 Nov 1977 1039-EST
From: LISKOV at MIT-DMS
Subject: Stoyan
Message-id: <[MIT-DMS].61509>
Dear John, I have told Jean to send the letter,
and she will do it as soon as she can (which may not
be til next week, since she will be out of town the
rest of this week). Whe wasn't certain whether she
had Stoyan's address; why don't you send it to me
so that won't be a problem.
I'm sorry things didn't work out more satisfactorily.
Barbara
∂08-Nov-77 1104 ZM Logic Quals
To: CG, MFB, WP
CC: JMC
As part of the preparation for the Logic Quals, I suggest that you study the special
issue of SIAM Journal on Computing (Sept. 1976) and take a look at the proceedings
of theoretical conferences held during the last two years. Zohar
∂08-Nov-77 1142 RWW samefringe
I couldn't reconstruct the algorithm last night. If you want me to
work on it more let me know.
rww
I also haven't been able to get it. If you can, I'd welcome it.
∂08-Nov-77 1412 BPM Exalt the auto
n520 0202 08 Nov 77
BC-Transport 2takes 11-08
Attention: Feature editors
By MORRIS S. THOMPSON
(c) 1977 Chicago Daily News
The American mass-transportation system - the auto-highway
complex - has made real the ancient dream of personal
mobility that was reflected in the myth of the centaur, giving
every man the liberty of movement once afforded only the
rich, and permitting the masses a quality of life previously
inconceivable. - B. Bruce-Briggs
xxx
Bruce-Briggs's book ''The War Against the Automobile''
is a first: He has written the only reasonably scholarly,
cogent and readable defense of the automobile as a means of
transportation and linchpin in the American way of life.
''The War Against the Automobile'' is a witty, trenchant
polemic whose arguments and writing style will anger some and
delight others, but will invariably provoke thought.
Bruce-Briggs has the hallmarks of the right-wing auto-erotic
critic of bureaucracy, grand plans and crusaders that he
apparently is. But the policy ideas he would contribute to public
debate outweigh his galling tendency towards rhetorical overkill
much like that of bureaucrats, grand planners and crusaders.
Bruce-Briggs argues persuasively that the real
mass-transportation system of the United States is the car.
For cost efficiency, convenience and relative safety,
it's powered by the internal-combustion engine.
He defends spiritedly one view of urban history: that urban and
suburban sprawl reflect the American craving for life in
places as little crowded as possible, that these impulses and
the enabling transportation networks antedate the rise of
the car. He also points out how much progress the automobile
has made in safety and pollution control.
Yet Bruce-Briggs' policy recommendations are far more
useful than any of his many, random, right-wing blatherings
and unnecessary (if sufficiently barbed to entertain)
character assassinations.
He sways this left-winger reluctantly to the thought that
U.S. transportation policy for the foreseeable future
should facilitate use of the automobile because of its
lower cost, greater benefit, higher flexibility and relative
safety.
He suggests that:
-Extension of roads into now-open countryside should be
planned, made public and carried out. That would enable people
and businesses to make decisions on where to locate on the
basis of their desire for a quiet or a convenient place.
Roads shouldn't be built where people don't want them.
-Iimprovements in the nation's transportation network
should be financed through a stiffer percentage tax on gasoline.
That's at root a progressive tax, with the tax paid dependent upon
relative use and consumption.
-Apportionment of most gas-tax revenues should be to
counties on the basis of the proportion of the U.S.
population each has. Some portion (Bruce-Briggs suggests
20 per cent) should go to state governments on the basis of the
proportion of total gas-tax revenues they collect. Use of
the funds should be entirely at the discretion of those
entities: cities that want mass transit could have it; those
who don't, wouldn't.
-Regulations on safety, emissions and fuel economy
should be reviewed with an eye to creative changes on the
bases of relative costs, benefits and hassles. He argues
inconclusively that stiffer safety and pollution standards
aren't needed. But Bruce-Briggs seems more intent upon
letting those who wish to kill themselves do so.
And while his expectation that free-market prices would
balloon available petroleum supplies is likely right, his
advocacy of consumption bridled only by ability to pay seems
short-sighted and hopelessly rooted in the unprovable
theory of the continuing progress of mankind through
science.
rr (More) 11-08
cd
...
(End missing.)
***************
n521 0202 08 Nov 77
BC-Auto 1stadd 11-08
Thompson xxx through science.
-Rapid-transit systems should give priority to buses and
build simple systems. Rights-of-way around rapid-transit
stations should be leased to businesses to help underwrite
the system. And he's quite right that great cost and little
benefit result from every city wanting subway cars of
unique design.
Bruce-Briggs presents challenging, iconclastic throughts in
a wide-ranging discussion of automobile culture and energy and
transportation policy. All-too-convincingly, he argues that
opposition to and support of America's automotive way of life
is based on what Max Weber, the German sociologist, called
'' 'elective affinities,' whereby peoples' values coincide
with their interests.''
His fundamental viewpoint will appeal to many: Americans are,
and should be, (he implies) most concerned about self-interest;
''life and nature are dirty;'' ''It is a little difficult
to understand why people are concerned about mountains
they will never see - especially since the terrain can be
restored to almost its natural contour once the coal is
extracted.'' (But would it be so without environmentalists'
pressures? Unequivocably, no.)
Queried on his reaction to the book, Ralph Nader, the
consumer activist, said he still stands by his own book
''Unsafe at Any Speed,'' which Bruce-Briggs attacks at length
and with relish.
(Bruce-Briggs' work) ''is like a book written by General
Motors' PR (public relations) department,'' Nader said.
''He's basically saying the problems (with the automobile)
aren't very serious.
''He's arguing that the car is a key to freedom. The whole
point is that poor people are required to buy cars and
spend 15 per cent of their income to get to work, when we
could have decent mass transit like people in Europe and
Japan. It isn't freedom when there's no choice.
''There are people who have honest disagreements on the way
to avoid tragedies. The problem with 'corporatists' like
Bruce-Briggs is that they'll slash at the means to eliminate
tragedies without offering an alternative,'' Nader said.
On the other hand, Lee A. Iacocca, president of Ford
Motor Co., enjoyed the positive book about his industry,
which he said has been wronged ''by those who would
have us walking instead of riding.'' He said the industry's
critics have too often displayed ''loose logic and
unrealistic expectations,'' creating a smokescreen through which
he says Bruce-Briggs sees.
Although Bruce-Briggs is generally willing to acknowledge
such merit as he sees in his opponents' arguments,
Bruce-Briggs' work seems to be too deeply rooted in an
understanding of the world as it is. And, of course, the
answers he gets are determined by the questions he asks.
Indeed, Bruce-Briggs fails to water the roots of the world
that might be. As the former Hudson Institute fellow surely
knows, those who think about the future, create it. Yet, in
our democratic decision-making, we Americans should be
careful not to become an even more selfish nation,
believing some men can be an island.
rr (Endit Thompson) 11-08
cd
...
(End missing.)
***************
∂08-Nov-77 1451 FTP:Taynai at SUMEX-AIM Ph.D. oral
Date: 8 NOV 1977 1450-PST
From: Taynai at SUMEX-AIM
Subject: Ph.D. oral
To: JMC at SAIL
cc: TAYNAI
Josh Knight is getting a Ph.D. minor in C.S. He must have a
CSD representative on his orals committee.
It is scheduld Friday, 2 p.m. December 2.
The topic is "Reverse Current in Solar Flares."
Josh is in Applied Physics.
Gio Wiederhold said he thought you would be interested in the
topic. MOst of the faculty is involved in teaching on Friday
afternoon.
Would you be interested and willing to participate in Josh's oral?
Please let me know.
Thank you,
Carolyn Tajnai
-------
∂08-Nov-77 1455 RWW samefringe
I worked on it about an hour. Couldn't seem to do it. I
wonder if I ever did. It seems to me it may not be possible.
rww
∂08-Nov-77 2206 SGK Economy
To: JMC, BH
What, in your opinion, causes unemployment?
Is welfare desirable? Justify your answer.
I am thinking about an alternative economics and think
reflecting on your answers will help me avoid pitfalls.
Thank you
∂09-Nov-77 1006 FTP:Feigenbaum at SUMEX-AIM visit by Marvin
Date: 9 NOV 1977 1005-PST
From: Feigenbaum at SUMEX-AIM
Subject: visit by Marvin
To: jmc at SAIL
I just got wind of a probable visit by Marvin to Stanford on
Nov. 28 for the SUMEX site visit. Perhaps we should prevail upoon him to
give our students a batch of lectures on Tuesday the 29th ("What Minsky
is thinking about these days"). Let's coordinate between ourselves about
this before contacting MM. What do you think?
Ed
-------
Sure, but why don't you just do it.
∂10-Nov-77 1238 FTP:MINSKY at MIT-AI (Marvin Minsky)
Date: 10 NOV 1977 1533-EST
From: MINSKY at MIT-AI (Marvin Minsky)
To: jmc at SU-AI
Michael fredkin is writing an essay about hobbits etc., for school.
Did you ever write a small essay about that or was it just
verbal burble? If anything, perhaps you could SEND it to MF@MIT-AI
Files labelled whose first name is HOBBIT in the directory
LIT,JMC at SU-AI have to do with hobbits. There are about nine
such files.
∂11-Nov-77 0047 LES Bureaucracy meeting
DCL would like to have a project leader's discussion of machine load
and account policy. How about Monday or Tuesday afternoon?
What is it you want to discuss and what are your views?
∂11-Nov-77 1033 FTP:Zenon Pylyshyn at CMU-10A A.I. - philosophy study group @ Stanford
Date: 11 Nov 1977 1332-EST
From: Zenon Pylyshyn at CMU-10A
Subject: A.I. - philosophy study group @ Stanford
To: jmc@sail
Sender: ZENON.PYLYSHYN at CMU-10A
Message-ID: [CMU-10A] 11 Nov 1977 13:32:11 Zenon Pylyshyn
I have just received your note of Nov 4 together with the prospectus
you submitted to the Center. It looks very interesting. If you
would like any comments or suggestions (e.g. re possible participants,
topics, etc) I would be glad to send them along. I log onto CMUA machine
once or twice a week (Bell telephone permitting) as part of my work for
the NSF-sponsored COSERS report (Computer Science and Engineering Research
Study) so I can be reached through the ARPANET (under the name appearing
in the header, among others). Keep me in touch with planning progress.
-------
Yes, I would definitely like your comments on the prospectus and
suggestions for participants.
∂11-Nov-77 1046 DCO
What is a reference to your semantics paper-to-be? " ??? ", to appear?
∂11-Nov-77 1719 MRC phone call
David Mintz from UC Beserkly called, 642-1035 irt BBN graphs of time domain
vs. amplitude of phonemes. Nobody was around who knew what this was about,
so I figured you would know. They want Xerox copies if possible; they don't
have anything.
∂11-Nov-77 2300 DCL bureaucracy
To: JMC, LES
I have noticed a distinct climb in the user population during this past
October and November, and an ever increasing use of cpu cycles by the
music project. I notice that many new music students on course 220
are placed straight onto the music project and run at any time
without restriction. At usually good times to compute - e.g., Saturday
and Sunday mornings - one can now look forward to competing for the cpu with
three or four jobs running the music compiler.
Although the music project is probably accounting for over 40% of the cpu
(Les, what are the figures for October?), they certainly are not the only
source of increase of users. I'm sure I dont notice everything.
(DON is a pretty big Trojan horse, for example.)
In any event the growing user
population appears to be totally unrestricted both in size and
privilege to run at all times. Certain days and times have already been
a complete disaster as regards doing any computation other than reading mail
in between lulls in activities that do not require the machine.
These are early days in the academic year, and experience shows that
the situation will grow worse. I would like to avert the pain
of competitive computing yet again.
The object of the proposed meeting is to set up some guidelines concerning
who can use the machine when. Hopefully, this will ensure that Lab. projects
can be certain of getting some competition-free computing at some times.
And that includes being able to xgp project related material without
waiting for a two or three hundred page song book to appear first.
∂12-Nov-77 0102 LES LLL visit
It is about time that we visit LLL and discuss plans. I propose to send
a message to Lowell Wood suggesting Friday as the day (I have a group
coming Wednesday, the Bell Labs people are supposed to come Thursday,
and Monday or Tuesday may be too soon). Would that mesh with your
schedule?
That's ok with me.
∂12-Nov-77 0120 LES
∂12-Nov-77 0112 JMC
Apropos DCL, what are prospects for time-recording bureaucracy?
[I just happen to be working on that now. Probably this weekend, assuming
that the accounting files are in good shape (there is some evidence that
they are not).]
∂13-Nov-77 0326 JBR
To: MRC
CC: JMC
∂13-Nov-77 0053 MRC previous message
Incidentally, this brings up another point I've been meaning to ask you.
Here the problem is clear, and a fix (at least one that works from the
user's point of view) is obvious and trivial.
Normally, I would patch the system and SYSTEM.DMP, and edit the source to have
the patch under an FTMRC (for "MRC messing around" ala FTJBR) switch that
you could turn off, AND note it in the log.
However, I didn't do any of this (other than a temporary patch which I
removed to be sure that was my problem) for fear of you snarling at me. I
believe I have a sense of where I know what I am doing irt the system and
where I should leave things for you by now, and I think it is silly for a
bug like that to stay in the system waiting for you to fix it when I could
have easily have taken care of it.
If you want me to continue with "hands off" (which I have) then fine, but
don't expect me to be able to learn anything about the system that way.
jbr: First of all, you weren't hired to either learn something about how
the system works internally, or to fix any bugs you might find. As to leaving
bugs in the system that you could have "easily taken care of", you could have
easily screwed the system up and caused endless confusion. So, to make things
clear, don't edit any of the system sources and don't patch the system any
more. If you find a bug, report it like everyone else. I'm sure that you
can wait the day or so to have bugs fixed, especially when they are relatively
insignificant to your work (that you have been hired to do) as in the current
case of the RUNTIM uuo. --jbr
∂13-Nov-77 0340 MRC irt JBR's message.
To: JBR
CC: JMC
mrc - I find that attitude to be offensive and condescending. On the one
hand, you say there is insufficient manpower to do this or that, but on the
other you jealously guard your domain as if I am trying to steal something
from you. If it makes you any happier, I am not out to take your job away
from you. Also, quite often I am the only person here in the wee hours of
the morning. I am, however, not going to argue with you; I'll leave that
to your conscience.
∂13-Nov-77 0344 JBR
To: MRC
CC: JMC, LES
∂13-Nov-77 0340 MRC irt JBR's message.
To: JBR
CC: JMC
mrc - I find that attitude to be offensive and condescending. On the one
hand, you say there is insufficient manpower to do this or that, but on the
other you jealously guard your domain as if I am trying to steal something
from you. If it makes you any happier, I am not out to take your job away
from you. Also, quite often I am the only person here in the wee hours of
the morning. I am, however, not going to argue with you; I'll leave that
to your conscience.
[How much more of this do I have to put up with. Please don't send me any
more messages about anything. I have had enough of you in my hair. I
find you most annoying. You will please confine your communications with me
to bug symptom reports in the gripes file. --jbr]
∂14-Nov-77 1534 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Study of electronic mail systems for the FCC
Date: 14 NOV 1977 1833-EST
From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
Subject: Study of electronic mail systems for the FCC
To: MCCARTHY at SU-AI
CC: SIRBU at MIT-MC
Dear Professor McCarthy:
The Center for Policy Alternatives at M.I.T. is currently conducting a study
for the Federal Communications Commission of Electronic Message Systems.
Our study is designed to provide a background on the subject to the FCC,
and to determine what new types of message services are being offered
or planned for offering over the next few years so that the Commission
may better anticipate the policy issues which these systems pose. The study
includes both computer message systems and communicating word processors.
I am presently planning a trip to the Palo Alto area to speak with a
number of firms and individuals who are actively concerned with
EMS, during the week of November 28. Professor Dunn has suggested
that I speak to you concerning the DIALNET project, which would
provide one important avenue towards universal electronic message
service. Would it be possible for us to get together either Tuesday
afternoon, November 29, or early Wednesday morning, the 30th?
Thanking you very much in advance for your cooperation, I remain
Very truly yours,
Marvin A. Sirbu, Jr.
4pm Tuesday the 29th is best, but Wednesday is also possible.
∂14-Nov-77 1718 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR TUESDAY 7 NOVEMBER
PLACE: ERL 237
TIME: 2.00 pm.
TITLE: Function and Procedure call rules in Hoare's Logic
SPEAKER: David Luckham
Various people have been trying to extend or generalize Hoare's
original rules of inference for function and procedure calls.
Some of them are inconsistent. I shall present some of them and
compare them with the rules currently in the verifier.
Steve German will present another extension to the procedure call
rule to allow function parameters in some cases.
∂14-Nov-77 1736 DCL
To: GROUP.DIS[VCG,DCL]:;
CORRECTION: SEMINAR IS ON NOV. 15th (TOMORROW!)
∂15-Nov-77 0001 LES
∂14-Nov-77 2212 JMC
What does Neil Miller do justifying his account?
[Not much. This started out as a barter arrangement: the group he worked
with (ARPA supported) gave us a bunch of line printer paper in exchange
for letting them do a few listings. Recently, he left them except for
occasional consulting and now works for an acoustic consulting firm
in the city. Have you noticed much activity?]
Just a few logins, e.g. tonight. However, there were a lot of users.
∂15-Nov-77 0213 LES LLL visit
To: JBR, JMC, ME, REG, TED
CC: LLW, LCW, TM, PMF
You are invited to visit LLL on Friday to kick the S-1 backpanel and
discuss possible projects. We will leave here at noon, get there about
1pm, and head back by 4 or so. If you want to eat, bring a bag.
If anyone would like to drive, feel free (we'll pay milage).
Otherwise, I can. If someone doesn't go we can fit in one car; else two.
∂15-Nov-77 0253 LES
CC: JMC, JBR
∂15-Nov-77 0240 LES YTD.DAT and friends
To: JAB
In trying to bring up SOB (Son of Bureaucracy), I find that the new-style
accounting files make no sense.
To permit examination of the data, I wrote a program (ACTEXT.SAI[F,ACT])
that coverts .DAT files into text files with the data for each PN
appearing as a line of text (the records for A, B, and C time are
enclosed in parentheses). Looking at the AUG.DAT file, for example,
I see a suspiciously large number of people with no A time, including
many who I know log in during the day time regularly. Even the record
for LES shows no A time and no Datmedia console time, even though I have
my Datamedia all year.
Comparison of JUL.DAT with AUG.DAT shows that two records have disappeared
at the beginning of the AUG file (PNs 100 and 2) and a number of the supposedly
cumulative totals have DECREASED! Clearly something is amiss.
∂15-Nov-77 0638 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
Date: 15 NOV 1977 0937-EST
From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
To: JMC at SU-AI
CC: SIRBU at MIT-MC
Let's make it 4 pm Tuesday the 29th. What building is
your office in?
The Artificial Intelligence Laboratory is not on the Stanford Campus.
Go West on Page Mill Road, and turn right on Arastradero Road just
after crossing under highway 280. The AI Lab is in the Donald
C. Power Building which is 0.8 miles on the right at 1600 Arastradero.
∂15-Nov-77 1324 PAT airline reservations
PSA #162, SJ to LAX departs 8:45 am arrives 9:40.
PSA #563, LAX to SJ departs 5:55 pm arrives 6:50.
tickets will be delivered this afternoon
∂15-Nov-77 1607 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 15 NOV 1977 1849-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
John,
I have not received the draft of your paper. Jean has sent off
a somewhat wishy washy letter anyway to Stoyan.
Sincerely,
A second draft was sent yesterday. I'll check that correct
address is being used. Better yet, mail
PAT@SU=ai your precise U.S. Mail co-ordinates.
Carl
P.S. Perhaps you could mail a draft of the paper directly to
Stoyan so that it will arrive at about the same time.
∂16-Nov-77 0756 FTP:JRBII@MIT-ML (Bob Boonstra)
Date: 16 NOV 1977 1056-EST
From: JRBII@MIT-ML (Bob Boonstra)
Sent-by: JRBII at MIT-ML
To: JMC at SU-AI
I would appreciate it if you would send me a copy of the
paper entitled "On the Model Theory of Knowledge," presented
at IJCAI-77, but not appearing in the Proceedings. I have
been unable to locate a copy here at MIT.
- Bob Boonstra
545 Tech Square, Rm 308
etc.
∂16-Nov-77 1004 FTP:Zenon Pylyshyn at CMU-10A Phone numbers, comments, etc
Date: 16 Nov 1977 1302-EST
From: Zenon Pylyshyn at CMU-10A
Subject: Phone numbers, comments, etc
To: JMC at SU-AI (John McCarthy)
Sender: ZENON.PYLYSHYN at CMU-10A
Message-ID: [CMU-10A] 16 Nov 1977 13:02:34 Zenon Pylyshyn
In-Reply-To: Your message of November 11, 1977
(1) My home number is (519)-433-1524. Office number (519)-679-2461
(2) The prospectus and the people you list both look generally very good.
Below are a few quick reactions. My own preference
might have been to include other Cognitive Science areas (e.g. philosophy
of mind and theoretically oriented cognitive psychology) while still
maintaining the focus on the epistemological issues - as described
in your prospectus. The trouble with this desiderata is the lack of
theoretically sophisticated people these adjacent areas (especially
cognitive psychology). The few people I immediately think of are very
likely not available next year: they include Al Newell, Jerry Fodor, and
David Marr (who I think of as a psychologist).
On the philosophical side Hilary Putnam, who you refer to a peripheral,
strikes me as one of the strongest possibilities. Other relevant
philosophers are Gil Harman, Ned Block, Keith Gunderson and Dana
Scott (for the logic side). It is much easier to find good philosophers
working in related areas than psychologists (which, by the way, makes
me wonder how Marty Ringle got on your list since my impression is that
he knows little about A.I. or related topics).
In A.I. some of the best candidates are in your neighborhood
(e.g. Winograd) so I needn't mention them. If I were to stick my neck
out for Cognitive Psychology I would probably mention Steve Isard,
Walter Kintsch, Allen Collins, Richard Gregory,
Dick Neisser, David Rumelhart, Stuart Sutherland and (though he is
not really a psychologist) Christopher Longuet-Higgens. I wish that
A.I. had got through to more thinkers in psychology but the few who
have been affected by it seem to be too busy running experiments to
consider the larger issues!
If I have any more thoughts about your plans in the next weeks
I will sent you a note.
-------
∂16-Nov-77 1231 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.) Request to change time of meeting on the 29th
Date: 16 NOV 1977 1530-EST
From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
Subject: Request to change time of meeting on the 29th
To: JMC at SU-AI
CC: SIRBU at MIT-MC
Professor Dunn has arranged for me to speak at the
Engineering Economics seminar on electronic message
systems at 4:00 p.m. Tuesday the 29th. Can we change
our meeting to 1:30 or 2:00?
Marvin
I teach until 2:30 on campus. We could meet then on campus or at 3pm
at the AI Lab.
∂16-Nov-77 2247 LES LLL visit
To: JMC, TED, JBR, REG
CC: PAT
Please respond to PAT.
∂16-Nov-77 2239 LLW via AMET Friday Visit Data Needs
To: LES
CC: TM, LCW, LLW
Could you please chave your secretary call mine
(charlotte Richmond at 415-4471100 X3444) as early as possible Thursday
with the names, citizenships, birthdates and addresses of
all those who may possibly be visiting over here on Friday (a slight
super-set of those actually showing up will be quite acceptable). I need
these data as soon as possible to make satisfactory arrangements with our
local security people. Thanks
Lowell
John McCarthy, U.S., Sept 4 1927, 846 Lathrop Dr. Stanford CA.
∂16-Nov-77 2323 DCL bureaucracy
To: LES
CC: JMC, WLS
Les, On the subject of 220 course students, which is admittedly only
one of the ways our machine cycles are being used, there are a number
of misunderstandings. It used to be that they were restricted to
0300-0900 hrs. I notice your statistics for October show no 220 usage at
all. But the music project accounted for 35% of total usage.
Are there any 220 students? Are they all now on the music project?
Have all restrictions on 220 students been lifted?
WLS complains of 220 jobs being run 1400-1700 weekday afternoons.
He says these are cpu cycle-soaking jobs.
If these people are really 220 students disguised as music project,
I think that maybe some restrictions should get reinstated pronto.
- D.
∂17-Nov-77 1034 PAT but you said...
yes, I know I said, but I thought it was better to coordinate with
Carolyn on macros and style so it will not be difficult to edit, so I will
finish it today since I talked with her yesterday afternoon.
∂18-Nov-77 0840 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
Date: 18 NOV 1977 1007-EST
From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
To: JMC at SU-AI
CC: SIRBU at MIT-MC
Let's meet at 2:30 on campus. Where should that be?
My class is in 152 Terman. We can go somewhere from there.
∂18-Nov-77 1426 100 : cr Phone Message
Eric Lacitis, Seattle Times (206)464-2237, would like you to call him back collect.
∂18-Nov-77 1627 DCO
... changed paragraph...
The question of the decidability of the first order theory of list structure
has recently been raised by John McCarthy [McCarthy 1977]; by the above it is
decidable. McCarthy showed that if one includes the predicate SUBEXPR(X,Y),
which asserts that x is a subexpression (subtree) of y, then the theory is
undecidable (every partial recursive function is definable in this augmented
theory).
∂19-Nov-77 0914 RDR via AMET long message
1) SCIP's AWG have been grumbling that grad students (who AWG thinks
they represent) don't get as much crunching as they used
to before LOTS. I think this might be true but what is baffling is the
question where the old SCIP budget went. These are not CS students, and CS
had all by itself $100K of the LOTS money, with only $5K for
"non-sponsored research". So the other departments must have only financed
LOTS at about $150K out of their $500K budgets and must have
SUBSTANTIAL funds left for graduate student "non-sponsored research." Nevertheless, a Psych grad student tells me that Psych's
principal bureaucrat Maxine Aiken told everyone "we're getting off SCIP"--
TOTALLY! Also, I talked to Physics' principal bureaucrat, Dave Haskin,
and he gave me the same impression. Can someone pry out of someone
what the current H&S allocations are--at least if it continues to
be an issue as far as sqwaking that LOTS should have internal
allocation schemes being answerable by pointing at the EXTERNAL
allocation situation.
2) IMSSS and SUMEX keep internally in their monitor a utilization
average (exponentially decayed like load averages are,
but with a 2.5 minute time cinstant it turns out). Already
it seemed like a good idea to make response time dependent upon
past service level realized and this is just an
observation on their implementation. This is a REALLY good idea
because the percentages could be displayed in SYSTAT and FINGER
and would make people more identifiable as far as using a lot goes.
3) As far as a handle or index on how response time is affecting
people how about using the number of sessions? I know it is sort of
people-dependent (how much is done in
one sitting) but over larg numbers of people and
over a good piece of time, this number would be meaningful I
have convinced myself. It is definitely dependent on
the response time and the number of terminals in the right way. The
uncertainty lies in the variability in what people want to do,
but that ought to cancel out over time; the number is VERY easy to
compute; if a 20% increase in terminals results in a DECREASE in the
number of sessions this would tend to indicate problems with response
time.
4) Somehow people have to realize that it is only natural for there
to be SOME waiting for a terminal. The current situation is bad but I
conjecture that what is needed is only 10 more terminals and not 30.
Of course, the other 20 will be needed soon enough, but they
shouldn't be used if response time suffers other than marginally.
∂19-Nov-77 2257 MRC
To: LES
CC: JMC
I updated the DIALnet protocols per my conversation with the Bell
Labs hackers and the results are in your mailbox. I agree with them;
the protocols are much much better with their suggested changes.
I also think they are right on the modem issue; 1200/1200 sounds like
what we advertised we were going to do. I don't think we are trying
to compete with the ARPAnet and at 4800 we actually are, if you believe
the transmission rates from this bagbiting system to the east coast.
Also, those modems are too expensive right now AND according to them
the market acceptance hasn't been too good. Finally, I have been told
that from a programming standpoint handling line turnaround is a real
drag.
Of course, you probably think I'm so enthusiastic about their ideas
because they agreed with me about multiple channels. Maybe you're
right (I respond quite nicely to pats on the head you see...).
I just had a talk with a friend of mine (MSC if you remember him) who
is a hacker at Sperry Univac. He might be in a position to get Univac
to do stuff with DIALnet.
∂19-Nov-77 2343 LES Dialnet & Bell Labs
To: MRC
CC: JMC
Given that you respond well to pats on the head, how do kicks in the rear
affect you?
I am afraid that you heard what you wanted to hear from Sandy and missed
at lot more because you were talking. For example, he did NOT argue in
favor of 1200/1200 baud modems; in fact he was against them. Instead he
favored 300/300 on grounds of general availability.
If we were trying to design a system out of immediately available hardware
and with minimal perturbation to operating systems, as he seemed to be
advocating, then we would use 300 baud modems and would develop protocols
similar to those of PCNET.
If we are trying to make the most of dialup lines, as I believe we are,
then we should attempt to exploit the available bandwidth and should
use protocols similar to those you have developed, but with the additions
needed to control asymmetric modems.
He also advocated replacing the CRC with a simpler checksum. I think
that is worth reexamining, but we should also consider the possibility
of conforming to one of the HDLC protocol variants and using an encoding
chip to do the checking hardwarily.
Another of his suggestions that looked sensible was to remove the
allocation field from your ACK command. I note that you haven't done
that.
It is not worthwhile arguing about whether to use 1200, 2400 or 4800
baud modems until we have more information about the costs of the
modems, their performance, and what programming problems may or may
not be associated with the higher speed modems.
∂19-Nov-77 2356 MRC
To: LES
CC: JMC
∂19-Nov-77 2343 LES Dialnet & Bell Labs
Given that you respond well to pats on the head, how do kicks in the rear
affect you?
POORLY; IN FACT I EITHER RESPOND IN A HOSTILE WAY OR NOT AT ALL.
HOWEVER, I AM TAKING THE THIRD APPROACH AND WILL TRY TO JUSTIFY
MY POSITION:
I am afraid that you heard what you wanted to hear from Sandy and missed
at lot more because you were talking. For example, he did NOT argue in
favor of 1200/1200 baud modems; in fact he was against them. Instead he
favored 300/300 on grounds of general availability.
I AGREE THAT 300/300 SHOULD BE A STANDARD SPEED ALONG WITH
1200/1200. HOW DOES THIS SOUND FOR PCNET ADVERTISEMENT:
The main financial obstacle against DIALnet is the
need for a special modem capable of 4800/150 baud
transmission and a special front end interface to
compute the checksum costing several thousand dollars.
In addition, the software costs of implementing line
turnaround are too much for many small systems to
afford.
SOUNDS FAMILIAR? THAT IS PARAPHRASED FROM OUR ADVERTISING.
I THINK THAT 1200/1200 IS HAIRY ENOUGH FOR MANY NEBBISH BUSINESS
SITES WITHOUT TALKING ABOUT 4800/150. THE LINE TURNAROUND CODE
ALONE WILL STOP MANY PLACES I AM SURE.
FINE IF WE CONSIDER IT AS ONE OF OUR OPTIONS, BUT I DO NOT WANT
TO SEE US LOCKED INTO IT IF IT TURNS OUT TO BE A LOSER. I THINK
THAT 1200/1200 IS A SURE THING, AND DEFINITELY 300/300 IS. WE
ARE STILL TALKING ABOUT MORE THAN PCNET IN ANY CASE.
IF 4800/150 TURNS OUT TO BE A LOSER AND DIALnet GETS WEDGED ON
IT IT WILL REFLECT BADLY ON ME, NOT ON YOU.
He also advocated replacing the CRC with a simpler checksum.
JBR MENTIONED THERE MIGHT BE A CRC-TYPE OF CHECKSUM WHICH
WORKED WITH 8. BITS AND HE WOULD LOOK INTO IT. I THINK IT
IS A WIN TO DO SO. I THINK WE SHOULD MINIMIZE THE SPECIAL
HARDWARE NEEDED.
Another of his suggestions that looked sensible was to remove the
allocation field from your ACK command. I note that you haven't done
that.
IT WAS ONE OF THE FEW THAT I CONDITIONALLY ACCEPTED, AND
IMPLEMENTED WITH BETTER DOCUMENTATION
I FEEL THAT IT IS PART OF MY JOB THAT IF I SEE SOMETHING HAPPENING
THAT IS WRONG I SHOULD SAY NO!! AND STOMP MY FOOT; AND THAT I WOULD
BE DERELICT IN MY DUTY IF I DIDN'T. I AM NOT ARGUING FOR THE SAKE
OF ARGUING.
∂19-Nov-77 2358 MRC
To: JMC
CC: LES
∂19-Nov-77 2350 JMC
It is not worthwhile arguing about whether to use 1200, 2400 or 4800
baud modems until we have more information about the costs of the
modems, their performance, and what programming problems may or may
not be associated with the higher speed modems.
OKAY.
∂20-Nov-77 1304 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR TUESDAY 22 NOVEMBER
PLACE: ERL 237
TIME: 2.30 pm.
TITLE: A Transformational Formalism for Program Correctness
SPEAKER: JACK SCHWARTZ
*********************************************************
Please note that the time has been changed to 2.30 this one time.
∂22-Nov-77 0131 CLT Ch2 Sect6
I have modified Ch2.6 according to your suggestions. In particular I added
the recommended sentence on p3. I also collected the discussion of
rectify etc. and the definitions and put them in a separate section. I will
put a copy in your mail box.
∂23-Nov-77 1259 ZM LOGIG QUALS
To: MFB, CG, WP
CC: JMC, ZM
The exam will be given at the AI Lab on Sat., Dec. 3:
Brooks - 10 am
Goad - 1 pm
Polak - 3 pm.
∂23-Nov-77 1319 ZM LOGIC QUALS - revised schedule
To: MFB, CG, WP
CC: JMC, ZM
Brooks - 9 am
Goad - 11 am
Polak - 1 pm
∂23-Nov-77 1451 PAT
To: ZM, TOB, JMC
∂23-Nov-77 1428 CCG
∂21-Nov-77 1214 FTP:
Date: 21 Nov 1977 (Monday) 1509-Est
From: AMAREL at RUTGERS-10
Subject: visit at stanford
To: ccg at SU-AI
cc: AMAREL
cordell,
i am planning to be at stanford on nov 28 and 29 in connection with the
SUMEX-AIM site visit. monday the 28 will be taken by the site visit, but i
have left open the evening of 28 and the 29. i would like very much to see
you and to find out what is going on in your project and in other areas of
the AI lab. i will appreciate it if you can arrange for us to meet; i would
also like to meet with mc carthy manna and binford if possible.
please send me a message (amarel@sumex-aim or amarel@rutgers-10) indicating
whether this can be scheduled.
regards, saul
α∧
[I will coordinate scheduling if you will let me know your preferences - patte]
∂24-Nov-77 0026 LES FR group
Here are the people listed in our directory under "Formal Reasoning".
If any should be flushed or added, please let me know.
DSB Dan Blom
EGD Edie Deak
REF Bob Filman
SEK Scott Kim
JCK Jim King
JMC John McCarthy
RCM Bob Moore
AMR Andrew Robinson
MS Masahiko Sato
CLT Carolyn Talcott
RWW Richard Weyhrauch
DEW Dave Wilkins
∂25-Nov-77 0004 LES SOB
I have put up the new accounting program despite the problem discussed in
the attached note to JAB. I attempted to include the disk-ops figure in
the summary, as you requested, but it doesn't fit; if it is added,
something else will have to go. The disk-ops data (and a lot more) IS
accessible by using the /RAW switch.
------------------------------
∂24-Nov-77 1641 LES Accounting inconsistency
To: JAB
CC: JBR
Having looked over the accounting files some more, I find they are
consistently inconsistent.
For example, take the records for HPM, who happens to be a heavy user.
YTD[ACT,SYS] for today shows that his total number of logins is 1976 and
OCT shows that the total through last month was 1798, implying that he
logged in 178 times during the first 23 days of November.
On the other hand, YTD.DAT shows 2006 logins for HPM and OCT.DAT shows
1847 logins, implying 165 for this month. So why does the old accounting
system show 8 more logins than the new?
This is not an isolated problem; in fact, it is very hard to find any
consistency between the two sets of records. It so happens that the
total number of logins this month according to the new accounting
system is 364 more than under the old. I find this scary. I do not
understand why they should not agree exactly.
The easy way to make the information fit is to use a smaller type font
on the XGP. If you use fix20, a full line printer page will print on
the XGP - or are you already using that?
∂25-Nov-77 1214 RWW scott kim
He has left the area and I thought all his stuff had disapeared. I
have not heard from him in a long time.
rww
∂25-Nov-77 1337 NH Hi. Am around, probably message at lenore morrell
will get me.
-----minsky
∂25-Nov-77 2001 ACH via UTAT ALT
With the latest optimization I discussed with you, the portable
compiler compiles ALT in six words, vs 11 for Diffie's compiler.
I don't know how to run the MACLISP compiler, otherwise I could give you
that number too.
The Standard code is:
(ENTRY ALT SUBR 1)
(ALLOC 0)
(LBL L1)
(JUMPNIL L2)
(LOAD 1 (CDR (REG 1)))
(JUMPNIL L2)
(LOAD 1 (CDR (REG 1)))
(JUMP L1)
(LBL L2)
(DEALLOC 0)
which translates in the PDP-10 to:(RETURN)
which translates to:
(JUMPE 1 L2)
(CDRA 1 0 1)
(JUMPE 1 L2)
(CDRA 1 0 1)
(JRST 0 L1)
L2
(POPJ P)
Tony
∂25-Nov-77 2237 DCO
I just picked up the mail at my old house and found your invitation
to last friday. I'm sorry I missed the affair. I am no longer living at
3852 Magnolia - my address is 113 Blackburn, Menlo Park.
∂26-Nov-77 1816 LES
∂25-Nov-77 0034 JMC
The easy way to make the information fit is to use a smaller type font
on the XGP. If you use fix20, a full line printer page will print on
the XGP - or are you already using that?
[Actually, there is already more than enough room on the XGP, but not on
terminals. Thus the only way more information can be added to the summary
is to make the terminal output ugly or make the XGP and LPT versions different.
Neither is very attractive.]
∂28-Nov-77 0000 JMC*
remember freewa.ns[ess,jmc]
∂28-Nov-77 1617 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR TUESDAY 29 NOVEMBER
PLACE: ERL 237
TIME: 2:00 pm.
TITLE: Features of FOL relevant to MTC
SPEAKER: RICHARD WEYHRAUCH
*********************************************************
Please note that the time is back to usual. i.e. 2:00
∂28-Nov-77 1717 JBR
You have exceeded your disk quota.
The files listed below have been purged to reduce your disk
area to your quota of 2000
Before purging, your files occupied 2831
You have too many files. The purger may not select the
optimum set.
SIGART.LST[LET,JMC]
ENERGY.LST[LET,JMC]
LEADER.LST[LET,JMC]
NEWELL.LST[LET,JMC]
GTREE.LST[206,JMC]
DIALNE.LST[DIA,JMC]
CRYPT.DMP[ 2,JMC]
CODE.DMP[ 2,JMC]
SOURC2.LAP[ 1,JMC]
FINAL.XGP[ 2,JMC]
DEATH.XGP[E77,JMC]
PARADO.XGP[E77,JMC]
MILLER.XGP[LET,JMC]
WEINER.XGP[LET,JMC]
MAIL.XGP[E77,JMC]
GRAPEV.XGP[LET,JMC]
COMMAN.XGP[E77,JMC]
DOGMIN.XGP[E77,JMC]
MINKER.XGP[LET,JMC]
TRIMBL.XGP[LET,JMC]
IMPURE.XGP[E77,JMC]
TODORO.XGP[LET,JMC]
MINIMA.XGP[S77,JMC]
NSF.XGP[E77,JMC]
RINGLE.XGP[LET,JMC]
CONCEP.XGP[E76,JMC]
DERIVE.XGP[ESS,JMC]
PRESS.XGP[DIA,JMC]
HOGAN.XGP[LET,JMC]
STOYAN.XGP[LET,JMC]
MIDTER.XGP[F77,JMC]
MORTEM.XGP[SEN,JMC]
SILVER.XGP[LET,JMC]
HARNAD.XGP[LET,JMC]
PROB.XGP[F77,JMC]
PENROD.XGP[LET,JMC]
PYLYSH.XGP[LET,JMC]
AFRICA.XGP[F77,JMC]
ESCAPE.XGP[F77,JMC]
KRIPKE.XGP[LET,JMC]
IMPURE.XGP[F77,JMC]
LISP.XGP[F77,JMC]
GINZBU.XGP[LET,JMC]
BRYNNE.XGP[LET,JMC]
MCPAIN.XGP[F77,JMC]
ANDREI.XGP[LET,JMC]
III.XGP[LET,JMC]
TIMES.XGP[LET,JMC]
JUSTIC.XGP[LET,JMC]
AIPHIL.XGP[F77,JMC]
MENTAL.XGP[F76,JMC]
DIALNE.XGP[DIA,JMC]
IJCAI.XGP[E77,JMC]
MAILAD.XGP[E77,JMC]
BLACK.XGP[LET,JMC]
REPRES.PRO[ 1,JMC]
FUNS[ 1,JMC]
EPIS[ 1,JMC]
P1[ 1,JMC]
PART[ 1,JMC]
PERM[ 1,JMC]
PATH2[ 1,JMC]
PATH[ 1,JMC]
ANTIN[ 1,JMC]
SYLL[ 1,JMC]
MEET[ 1,JMC]
COMPIL[ 1,JMC]
TIMES[ 1,JMC]
TESTA.SAI[ 1,JMC]
TESTC.SAI[ 1,JMC]
TESTB.SAI[ 1,JMC]
TESTD.SAI[ 1,JMC]
DADDA[ 1,JMC]
ORDIN[ 1,JMC]
PROB1[ 1,JMC]
ROTAT.SAI[ 1,JMC]
ROTA.SAI[ 1,JMC]
ROTB.SAI[ 1,JMC]
ROTC.SAI[ 1,JMC]
SEMAA[ 1,JMC]
SEMAB[ 1,JMC]
INTER[ 1,JMC]
CONVER.SAI[ 1,JMC]
RELREP[ 1,JMC]
FWGC[245,JMC]
MC[245,JMC]
PATH[245,JMC]
PATH2[245,JMC]
DEMO[ 1,JMC]
LISPAD[ 1,JMC]
TESTE.SAI[ 1,JMC]
ICOM[ 1,JMC]
TRANS1[ 1,JMC]
SIMUL[ 1,JMC]
COMPU2[ 1,JMC]
SOURCE[ 1,JMC]
SOURC2[ 1,JMC]
PUZZ.SAI[ 1,JMC]
TCLUB[ 1,JMC]
TCLUBA[ 1,JMC]
NEWDOC[ 1,JMC]
BOARDS.SAI[ 1,JMC]
REFER.ENC[225,JMC]
MCCRAC.LET[ 1,JMC]
PATHS.RLS[225,JMC]
PARKER[ 1,JMC]
GRPALG.RLS[225,JMC]
GRPDAT.RLS[225,JMC]
GROPER.RLS[225,JMC]
DIMEN.RLS[225,JMC]
CHAR.RLS[225,JMC]
LARRY2[ 1,JMC]
COMPU2.LET[ 1,JMC]
DEG5.IN[225,JMC]
S4.REP[225,JMC]
REPRES.RLS[225,JMC]
DEG6.IN[225,JMC]
R42.IN[225,JMC]
ANNOUN[225,JMC]
PUZZ.SAI[225,JMC]
PUZZA.SAI[225,JMC]
PANIC.SOS[225,JMC]
PUZZB.SAI[225,JMC]
ENCYC1.PRO[ESS,JMC]
PUZZE.SAI[225,JMC]
DRIVE.DIR[ AI,JMC]
MINE.DIR[ AI,JMC]
PTCH2.DIR[ AI,JMC]
KNOW2.AI[ESS,JMC]
ARTNA1.ART[ESS,JMC]
RECOG.LET[ 1,JMC]
MEMMTC.QUA[ESS,JMC]
LANG1.AI[ESS,JMC]
S5.QUA[ESS,JMC]
MTC71.QUA[ESS,JMC]
R1303.ART[ESS,JMC]
R1301.ART[ESS,JMC]
N30[ 1,JMC]
QA.PRO[ESS,JMC]
ARTNAT.ART[ESS,JMC]
SEMAN.AI[ESS,JMC]
FRANK.STA[ESS,JMC]
MTCSYL.QUA[ESS,JMC]
COMPUT.STA[ESS,JMC]
AISY69.QUA[ESS,JMC]
FILEC.FAI[ESS,JMC]
LETTVI.REV[ESS,JMC]
R1300.ART[ESS,JMC]
LCFMEM.MTC[ESS,JMC]
PEARL.NOT[ESS,JMC]
PUZZ.RLS[226,JMC]
PUZB.SAI[226,JMC]
PUZZ.SAI[226,JMC]
TRANS.DOC[226,JMC]
BLISET.PRF[226,JMC]
BLISET.COM[226,JMC]
IMPROV.DOC[226,JMC]
SETRUL.DOC[226,JMC]
PCHECK.M2[226,JMC]
COND.PRF[226,JMC]
BACKSL[ 1,JMC]
SYSTEM.HAC[226,JMC]
SORTS.DOC[226,JMC]
ADD.PRF[226,JMC]
TH1.PRF[226,JMC]
TH1.COM[226,JMC]
PCHECK.M1[226,JMC]
ADD.COM[226,JMC]
NETJO2.PRO[ESS,JMC]
FALSE.PRF[226,JMC]
DI[226,JMC]
SCWORL.AX2[226,JMC]
ONE.PRF[226,JMC]
IPT73.REP[ESS,JMC]
NSFX.5[ESS,JMC]
NSFX.7[ESS,JMC]
NSFX.9[ESS,JMC]
NSFX.2[ESS,JMC]
NSFX.6[ESS,JMC]
NSFX.8[ESS,JMC]
NSFX.4[ESS,JMC]
NSFX.3[ESS,JMC]
HAYES.FRM[ESS,JMC]
ADTEL2.NOT[ESS,JMC]
PLATT.NOT[ESS,JMC]
REPRES.BIB[226,JMC]
ONTO.NOT[226,JMC]
TASK2.MAR[ESS,JMC]
TASK1.MAR[ESS,JMC]
LETTER.HE2[ESS,JMC]
XLET[ESS,JMC]
ZF.AX[ESS,JMC]
FOO73A[ESS,JMC]
FOON.PR1[ESS,JMC]
ROTD.SAI[ 1,JMC]
ROTE.SAI[ 1,JMC]
ROTF.SAI[ 1,JMC]
SWOPSI.RE[ESS,JMC]
HART.ME1[ESS,JMC]
GGGG[ESS,JMC]
PRO[ESS,JMC]
M29AUG.MES[ESS,JMC]
SYMPOS[ESS,JMC]
CH1.BH2[ESS,JMC]
CLOCK.FAI[ESS,JMC]
FONTS[ESS,JMC]
SLIDES[ESS,JMC]
FACMIN.MEM[ 1,JMC]
W74.PLN[226,JMC]
CLASS.REG[226,JMC]
GAME.CHK[226,JMC]
FOO1[ESS,JMC]
FOL2.MEM[226,JMC]
FOL1.MEM[226,JMC]
WUTHER.QUE[ESS,JMC]
ROY[LET,JMC]
TOLLES.LET[LET,JMC]
FORDH.LET[LET,JMC]
AD.NET[ESS,JMC]
NEWRUL.DOC[226,JMC]
COMPUT[ 1,JMC]
KNUTH.SAI[225,JMC]
TUCKER.LE2[LET,JMC]
TOLLES.LE1[LET,JMC]
TUCKER.LET[LET,JMC]
TCLUB.MEM[ESS,JMC]
PUTCH[ AI,JMC]
PUTCH.DIR[ AI,JMC]
DRIVE[ AI,JMC]
AIBIB[ AI,JMC]
MINE[ AI,JMC]
NOTES2[ AI,JMC]
PUTCH3[ AI,JMC]
RUSS[ AI,JMC]
CHYLIN.LE1[ AI,JMC]
GEN1[ AI,JMC]
DRIVE3[ AI,JMC]
MPRO[ AI,JMC]
SLAMEC.LE2[LET,JMC]
BOWDEN.LE1[LET,JMC]
CHERN.LE2[LET,JMC]
MAY.ME[LET,JMC]
NSFX.10[ESS,JMC]
HENRY[ESS,JMC]
MC.AI[ESS,JMC]
BIRKHO.LE1[LET,JMC]
FLANAG.LE1[LET,JMC]
ERIK.LE6[LET,JMC]
TAMBOV[ 1,JMC]
BARAB[ 1,JMC]
HARPER.LE1[LET,JMC]
PUZZE.F4[225,JMC]
ERIK.LE7[LET,JMC]
BAJCSY.LE1[LET,JMC]
STARKM.LE1[LET,JMC]
MT[ 1,JMC]
BRIT.LET[LET,JMC]
IRANI.LE1[LET,JMC]
BOWEN.LE1[LET,JMC]
JAF.STA[ESS,JMC]
RECUR[ESS,JMC]
ANDERS.RE1[ 1,JMC]
PEOPLE[226,JMC]
FLESS.LE1[LET,JMC]
TRESSL.LE1[LET,JMC]
PIASET.LE2[LET,JMC]
LICKL.LE1[LET,JMC]
COOP.LE1[LET,JMC]
POE.LE1[LET,JMC]
JMILLE.LE2[LET,JMC]
IGARAS.LE1[LET,JMC]
ITO.LE1[LET,JMC]
CLARK.LE1[LET,JMC]
FLESS.LE2[LET,JMC]
MICHIE.LE3[LET,JMC]
TAVARE.LE1[LET,JMC]
SCIENC.LE1[LET,JMC]
SCRIB.LE1[LET,JMC]
ATKIN.LE1[LET,JMC]
KOCHEN.LE1[LET,JMC]
GREER.FAC[LET,JMC]
CU.LE1[LET,JMC]
RALSTO.LE2[LET,JMC]
MESSAG.SCI[LET,JMC]
MCCRAC.LE2[LET,JMC]
RALSTO.LE3[LET,JMC]
CHRON.LE1[LET,JMC]
LOGIC.QUA[LET,JMC]
SHIGER.LE1[LET,JMC]
PAMELA.LE1[LET,JMC]
TAUGNE.LE1[LET,JMC]
MORGAN.LE2[LET,JMC]
FROOK.LE1[LET,JMC]
LOMONA.LE1[LET,JMC]
APR.ME[LET,JMC]
LOGIC.PUB[LET,JMC]
CONSUL.LE1[LET,JMC]
VERE.LE1[LET,JMC]
PAWLAK.LE1[LET,JMC]
TSUDA.LE1[LET,JMC]
NOLL.LE1[LET,JMC]
ROBERT.LE1[LET,JMC]
RILI.LE1[LET,JMC]
RALSTO.LE1[LET,JMC]
MORGAN.LE1[LET,JMC]
MIYA.LE1[LET,JMC]
HEALTH.LE1[LET,JMC]
WILKS.LE1[LET,JMC]
LAST.LE1[LET,JMC]
SEDEL.LE1[LET,JMC]
CAMPB.LE1[LET,JMC]
ARDEN.LE1[LET,JMC]
BURNS.LE1[LET,JMC]
SHOCK.LE1[LET,JMC]
CU.LE2[LET,JMC]
DAVID.LE1[LET,JMC]
SCHOEL.LE1[LET,JMC]
CALHOU.LE1[LET,JMC]
FINCH.LE1[LET,JMC]
LYKOS.LE1[LET,JMC]
JMILLE.LE1[LET,JMC]
MITCH.LE1[LET,JMC]
JERRY.LE1[LET,JMC]
MCQUIL.LE1[LET,JMC]
PAM.LE1[LET,JMC]
DRLUK.LE1[LET,JMC]
OCT.ME[LET,JMC]
OLSEN.LE1[LET,JMC]
ERIK.LE0[LET,JMC]
SUBCOM.LE1[LET,JMC]
MICHIE.LE2[LET,JMC]
NEWSCI.LE1[LET,JMC]
AHLHAU.LE1[LET,JMC]
MEMOS.CUR[LET,JMC]
PUBINT.LE1[LET,JMC]
HORNIN.LE1[LET,JMC]
FELDST.LE1[LET,JMC]
CHECK.DEP[LET,JMC]
TUCKER.LE1[LET,JMC]
SCANDU.LE1[LET,JMC]
MELTZ.LE1[LET,JMC]
PIASET.LE1[LET,JMC]
MILNER.REC[LET,JMC]
FORSHA.LE1[LET,JMC]
COMPT.LE1[LET,JMC]
STORK.LE1[LET,JMC]
R1302.ART[ESS,JMC]
ASTRO2.ART[ESS,JMC]
FRIEDM.LE1[LET,JMC]
FF[ESS,JMC]
AIRLIN.MTC[ESS,JMC]
JFOL.USE[ESS,JMC]
MEARS.LET[LET,JMC]
GRIMM.BKP[ESS,JMC]
SCIAM.LE1[LET,JMC]
NYT.LE1[LET,JMC]
NAVROZ.LE1[LET,JMC]
TECH[ 1,JMC]
NOTES1[ AI,JMC]
LISPN[ 1,JMC]
TXP1.LSP[ 1,JMC]
STARK.LE1[LET,JMC]
IGARAS.LE2[LET,JMC]
REPRES[LET,JMC]
MDAVIS.LE1[LET,JMC]
KNOW.NOT[ AI,JMC]
GLUGG[LIT,JMC]
GLUGG2[LIT,JMC]
KNOW.ART[ AI,JMC]
FLESS.LE0[LET,JMC]
TELLER.LE1[LET,JMC]
PERSON[ 1,JMC]
YOUNG.LE1[LET,JMC]
KILPAT.LE1[LET,JMC]
JAF.STA[LET,JMC]
PIERCE[ 1,JMC]
MEIR.LE1[LET,JMC]
JAF.LE2[LET,JMC]
LARRY[ 1,JMC]
MCCRAC.LE1[LET,JMC]
NAS.NOT[ESS,JMC]
CRYPT.FAI[ 2,JMC]
WEISSK.LE1[LET,JMC]
MICHIE.LE1[LET,JMC]
AAAS.PRO[ESS,JMC]
3D.NSF[ESS,JMC]
ONEILL.NOT[ESS,JMC]
ISRAEL.LE1[LET,JMC]
ISRAEL.ART[LET,JMC]
CHENEY.LE1[LET,JMC]
OCTOBE.OUT[LET,JMC]
ONEILL.LE1[LET,JMC]
CORBAT.LE1[LET,JMC]
CALHOU.LE2[LET,JMC]
COMTOP.LIS[ESS,JMC]
COMNEE[ 1,JMC]
EFOO[ESS,JMC]
MICHIE.LE4[LET,JMC]
INFO.NEE[ESS,JMC]
LIB.PRO[ 1,JMC]
NET1[ 1,JMC]
NAMES[ESS,JMC]
AIMEM2.JMC[226,JMC]
EVANS.LE1[LET,JMC]
EVANS.LE2[LET,JMC]
NETDOC.PLN[ESS,JMC]
ALUMNI[ 1,JMC]
INFO[ 1,JMC]
SUFFIC.FRE[LET,JMC]
OLIVER.LE1[LET,JMC]
OCT.USE[ESS,JMC]
INTRO.AI[ 2,JMC]
ADMIS.LET[LET,JMC]
COMMON.NS[LET,JMC]
DRELL.LE1[LET,JMC]
SIGART.BUL[LET,JMC]
SIGART.LE2[LET,JMC]
SIGART.LE1[LET,JMC]
RUSSOF.NOT[ESS,JMC]
BOWEN.LE2[LET,JMC]
INVOIC[LET,JMC]
ACM.LE2[LET,JMC]
ACM.LE1[LET,JMC]
JOSHI.LE1[LET,JMC]
FERRIS.LE1[LET,JMC]
NYT.LE2[LET,JMC]
SOCIAL[ 1,JMC]
AILAB.AIL[ESS,JMC]
BDAY.LIT[LIT,JMC]
ACTOR0[258,JMC]
NONTER.PRB[258,JMC]
CORREC.ABS[258,JMC]
BACKUP.MCP[258,JMC]
HOMOMO.NOT[258,JMC]
BRACEW.LE1[LET,JMC]
MCP.PR1[258,JMC]
COND.PRF[258,JMC]
PQR.PRF[258,JMC]
SCHEM.WRU[258,JMC]
GREEK.JMC[258,JMC]
MCCUS.PRO[258,JMC]
FOLSCO.MEM[258,JMC]
EXTFOR.MEM[258,JMC]
NAUR.LE1[LET,JMC]
FEMANO.LE1[LET,JMC]
MTC.GRP[ESS,JMC]
PETERS.LE1[LET,JMC]
JAN.ME[LET,JMC]
LEGUIN.CRI[LIT,JMC]
JAN14.DBX[258,JMC]
SUM.CAR[ 1,JMC]
ESSEX.LE1[LET,JMC]
GELLMA.LE1[LET,JMC]
SHELDO.NS[LET,JMC]
APPEND.CON[258,JMC]
LOOKUP.SPE[ 1,JMC]
FOLMAN.MOD[258,JMC]
HOBBS.LE1[LET,JMC]
BREMER.LE1[LET,JMC]
CONSUL.POX[ESS,JMC]
AILET[LET,JMC]
REYNOL.LE1[LET,JMC]
ACM.LE3[LET,JMC]
LEAST.CM1[258,JMC]
NORBYE.LE1[LET,JMC]
JAN.OUT[LET,JMC]
DEC74.IN[LET,JMC]
HAND.2[258,JMC]
JO.NOT[258,JMC]
MTC.BLA[258,JMC]
LOGIC.QUA[258,JMC]
OUTLIN.256[258,JMC]
HARDPR.OOF[258,JMC]
MANNA.WRU[258,JMC]
DEMO.PR1[258,JMC]
HAND3.W75[258,JMC]
HAND.W75[258,JMC]
MANNA.PR2[258,JMC]
MANNA.CM2[258,JMC]
OKAMOT.LE1[LET,JMC]
VIS[ 2,JMC]
VIS1[ 2,JMC]
VIS.CAP[ 2,JMC]
NNN[ 2,JMC]
VITASK[ 2,JMC]
CHRI.LE1[ 2,JMC]
FRAGA.LE1[LET,JMC]
GORDON.LE2[LET,JMC]
FIELDS.ME2[LET,JMC]
ENERGY.LE1[LET,JMC]
GORDON.LE1[LET,JMC]
TASK[LIT,JMC]
FEB.ME[LET,JMC]
DEC.ME[LET,JMC]
ADHOC.THE[258,JMC]
SAKAI.LE1[LET,JMC]
LICK[ESS,JMC]
LICK.LE1[LET,JMC]
LICK.ME1[LET,JMC]
PARTIT.LSP[ 1,JMC]
HAND.1[258,JMC]
BIBLE[245,JMC]
USER[245,JMC]
IDEAS[225,JMC]
SUZUKI.REC[LET,JMC]
SAKAI.LE2[LET,JMC]
MUFTIC.LE1[LET,JMC]
VOR1[ 1,JMC]
SCWORL.AX[226,JMC]
INTEG2.AX[258,JMC]
COND.AX[258,JMC]
W0.AX[226,JMC]
EQUA.AX[226,JMC]
ORD2.AX[226,JMC]
SEQ.AX[226,JMC]
LISP.AX[226,JMC]
INDUC.AX[258,JMC]
INTEGE.AX[258,JMC]
COMPIL.AX[258,JMC]
ADMIND.AX[226,JMC]
SCOTT.AX[226,JMC]
SET3.AX[226,JMC]
SET2.AX[226,JMC]
BLISET.AX[226,JMC]
ZF.AX[258,JMC]
EQUAL.AX[258,JMC]
EXTFOR.AX[258,JMC]
COND.AX[226,JMC]
IGR.AX[226,JMC]
SCINT.AX[226,JMC]
ORD1.AX[226,JMC]
LIST.AX[226,JMC]
MCP.AX[258,JMC]
MCP2.AX[258,JMC]
MCP3.AX[258,JMC]
REST.AX[226,JMC]
TERMS.AX[226,JMC]
SET.AX[226,JMC]
INT.AX[226,JMC]
MRHUG.QUE[226,JMC]
ASHLEY.LE1[LET,JMC]
74DEC1.AJT[LET,JMC]
WEINER.ME1[LET,JMC]
WEINER.GRP[LET,JMC]
WEINER.ME2[LET,JMC]
SMITH.LE1[LET,JMC]
GAREY.LE1[LET,JMC]
BERG.LE2[LET,JMC]
KOREA.2[S75,JMC]
KOREA.POL[S75,JMC]
ENGINE.LE1[LET,JMC]
RUSSIA.LE1[LET,JMC]
GELFAN.LE1[LET,JMC]
MT.PRO[ 1,JMC]
JUL75.OUT[MSG,JMC]
AUG75.OUT[MSG,JMC]
SEP75.OUT[MSG,JMC]
JAN75.OUT[MSG,JMC]
DEC74.OUT[MSG,JMC]
MAR75.OUT[MSG,JMC]
APR75.OUT[MSG,JMC]
MAY75.OUT[MSG,JMC]
JUN75.OUT[MSG,JMC]
APR75.IN[MSG,JMC]
MAR75.IN[MSG,JMC]
INGERM.LE1[LET,JMC]
SQUIBS.PRO[ 1,JMC]
FRA[ 1,JMC]
FR2[ 1,JMC]
MODEST[S75,JMC]
SCIP[CUR,JMC]
IDEOLO[CUR,JMC]
ECON.NOT[CUR,JMC]
AICIRC.ABS[CUR,JMC]
CPDUST[CUR,JMC]
IDEOLO.ART[CUR,JMC]
APHOR.AI[CUR,JMC]
ECO.ESS[CUR,JMC]
RACKET.ESS[CUR,JMC]
PROPOS.BLA[CUR,JMC]
PHIL[CUR,JMC]
COMMON[CUR,JMC]
MENTAL[CUR,JMC]
NEWS75.MOD[CUR,JMC]
EXEC.SUM[CUR,JMC]
PRODUC.ESS[CUR,JMC]
STANDA.ESS[CUR,JMC]
ARPMTC[CUR,JMC]
IDEOLO.ESS[CUR,JMC]
CHESS1[CUR,JMC]
SOCIAL.DEF[CUR,JMC]
RAMSEY[CUR,JMC]
HOW.ESS[CUR,JMC]
LEADER.ART[CUR,JMC]
LICK.PRE[CUR,JMC]
REPRES.LIC[CUR,JMC]
REPRES.LI2[CUR,JMC]
GOALS.LIC[CUR,JMC]
TWOMOD.ESS[CUR,JMC]
FORMAL.PRO[CUR,JMC]
SALARY.MEM[CUR,JMC]
ARPA75.OUT[MSG,JMC]
1974.IN[MSG,JMC]
JAN75.IN[MSG,JMC]
JUL75.IN[MSG,JMC]
FEB75.IN[MSG,JMC]
AUG75.IN[MSG,JMC]
XGPPUB.1[ESS,JMC]
ADMIT.PUB[CUR,JMC]
KHABAR.AI[S75,JMC]
NEWS75.SUP[ESS,JMC]
NAKATA.LE1[LET,JMC]
HENDRI.REV[ESS,JMC]
TWOEAS.MEM[258,JMC]
REPRES.DOC[ESS,JMC]
REPRES.NOT[ESS,JMC]
LEM.LE1[LET,JMC]
SCHULT.LE1[LET,JMC]
REPRES.REP[ESS,JMC]
HOMER.LE1[LET,JMC]
OPTIM[F75,JMC]
LUMELS.LE1[LET,JMC]
DYSON.LE1[LET,JMC]
RUSSEL.ME1[LET,JMC]
NEWBOR.REV[F75,JMC]
TASK.TA[F75,JMC]
NICK.FIL[F75,JMC]
SEXP[F75,JMC]
AI[F75,JMC]
LATIME.LE1[LET,JMC]
GENERA[F75,JMC]
SANDEW.LE2[LET,JMC]
LISP.MAN[S75,JMC]
PHIL.ART[F75,JMC]
DEFINE[F75,JMC]
BULLET[F75,JMC]
DATA1.204[F75,JMC]
DATA4.204[F75,JMC]
DATA3.204[F75,JMC]
ISHII.LE1[LET,JMC]
TEXTOR.LE1[LET,JMC]
ED1.DO[ESS,JMC]
EDH.DO[ESS,JMC]
OFFICE.PLN[F75,JMC]
AIORG.PLN[ 1,JMC]
REPRES.P75[ 1,JMC]
IJCAI.DOC[F75,JMC]
ASHENH.LE2[LET,JMC]
IJCAI.ENQ[F75,JMC]
ASHENH.LE1[LET,JMC]
AAAS[ESS,JMC]
DCL2.75[LET,JMC]
LUK.LE1[ 2,JMC]
AAAS.76[ESS,JMC]
LUCKHA.LE1[LET,JMC]
HOARE.LE1[LET,JMC]
SCIENC.LE3[LET,JMC]
ABELSO.LE1[LET,JMC]
NILSSO.ME1[LET,JMC]
SCIENC.LE2[LET,JMC]
HJERPP.LE1[LET,JMC]
MOSES.LE1[LET,JMC]
RELATI.POX[CUR,JMC]
BROWN.LE1[LET,JMC]
GILFIL.REV[F75,JMC]
SCOTT.LE1[LET,JMC]
SENSE.AD[LET,JMC]
PR1.DEC[F75,JMC]
AJT.MEM[ESS,JMC]
RAWLS.REV[ESS,JMC]
CYCLOP[F75,JMC]
SENSE.POS[F75,JMC]
GINI.LE1[LET,JMC]
MARTEL.LE1[LET,JMC]
MARTEL.DOC[LET,JMC]
FRIED.LE1[LET,JMC]
ROTH.LE1[LET,JMC]
FRIED.LE2[LET,JMC]
BRINKE.LE1[LET,JMC]
FIX[F75,JMC]
FIXUP.LBK[F75,JMC]
TABLE[F75,JMC]
BLIROB.AX[226,JMC]
BLIROB.DOC[226,JMC]
TERMPA.206[F75,JMC]
FIXUP2.LBK[F75,JMC]
RYLE.REV[F75,JMC]
FIXUP[F75,JMC]
TUNNEY.LE1[LET,JMC]
BLIROB.COM[226,JMC]
FIXUP2[F75,JMC]
NEWS75.PUB[CUR,JMC]
BRINKL.LE1[LET,JMC]
JAF.LE1[LET,JMC]
GARDNE.LE2[LET,JMC]
SENSE.LE1[LET,JMC]
MOTIV.ART[ AI,JMC]
DAILY.ART[F75,JMC]
SENSE.LE2[LET,JMC]
REVAL2.LBK[F75,JMC]
REVAL3.LBK[F75,JMC]
AUTOMA.2[F75,JMC]
AUTOMA[F75,JMC]
COUNTE[F75,JMC]
PR1.AX[F75,JMC]
HOTER.1[CUR,JMC]
HOTER[CUR,JMC]
MELTZE.LE[LET,JMC]
NOV.ME[LET,JMC]
HEAD.LET[LET,JMC]
MACHIN[F75,JMC]
BETHE.LE1[LET,JMC]
SENSE.DAT[F75,JMC]
GOLDMA.LE1[ 2,JMC]
BETHE.LE2[LET,JMC]
FINITI[F75,JMC]
SOULE.LE1[LET,JMC]
THESIS[F75,JMC]
SCIENT.LE1[LET,JMC]
MINIMA[F75,JMC]
FIB[F75,JMC]
DEC75.IN[LET,JMC]
YOST.LE1[LET,JMC]
FIELDS.SUP[LET,JMC]
NEWYOR.LE1[LET,JMC]
KAHN.LE1[LET,JMC]
FIELDS.ME1[LET,JMC]
BLEDSO.LE1[LET,JMC]
BLEDSO.DOC[LET,JMC]
GABOR.LE1[LET,JMC]
RAPHAE.LE1[LET,JMC]
GARDNE.LE1[LET,JMC]
CHERN.LE1[LET,JMC]
RHODES.LE1[LET,JMC]
LISP.INT[F75,JMC]
BLOCKS.226[F75,JMC]
NOTES.226[F75,JMC]
TAUT.PRF[F75,JMC]
UTILI.AIL[F75,JMC]
MOSSIG.LE1[LET,JMC]
PET.LIT[LIT,JMC]
TOLEDO.LE1[LET,JMC]
CBCL[F75,JMC]
SET[F75,JMC]
SET.AX[F75,JMC]
SENSE.LE3[LET,JMC]
FILMAN.RE2[LET,JMC]
CONS.AX[226,JMC]
SMULLY[226,JMC]
GIL1[ 2,JMC]
KNOPOF.LE1[LET,JMC]
YAMADA.LE1[LET,JMC]
CULIK.LE1[LET,JMC]
ANDREI.ADR[ESS,JMC]
JAN76.IN[LET,JMC]
MILLER.LE0[LET,JMC]
LUCKHA.BLA[F75,JMC]
JAN76.OUT[LET,JMC]
ARPA75.IN[MSG,JMC]
ADMIT.TEL[LET,JMC]
LICK.1[LET,JMC]
MENTAL.NOT[F75,JMC]
PHIL.ART[ESS,JMC]
∂28-Nov-77 2124 REF AI lab seminar
We are planning to start an A.I. lab seminar next quarter.
It is intended as an opportunity for senior graduate students to
present their research to the rest of the lab. This will provide
both a good opportunity for them to practice research presentation, and
a good opportunity for all of us to become better acquainted with the
work of other research groups.
Of course, arranging this seminar requires speakers. What I would
like from you is a list of your students who are sufficiently far along
in their research as to be capable of making a good presentation.
Thanks for your attention, time and effort.
Bob
∂29-Nov-77 0811 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 29 NOV 1977 1110-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
John:
Could you please have your secretary send a copy of your paper to
Professor Henry Tropp
Dept. of Mathematics
Humboldt State Univ.
Arcata, CA 95521
Also what do you think of sending copies to all the people who participated
in the original development of LISP (i.e. the ones listed as authors in the LISP
manual?
Your old copy of your paper finally arrived via U.S. mail yesterday.
Sincrely,
Carl
∂29-Nov-77 0852 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 29 NOV 1977 1152-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
***In an appendix it might be worthwile to present the definition
of EVAL together with the modification that makes upward funargs work.***
John: The definition of eval on page 13 of the the LISP 1.5 manuaul
does not have upward funargs; but the definition on page 71 does work with
upward funargs. Theses interpreters can be cleaned up and simplified
to make the point. Would you like me to do it or would you rather
proceed on your own?
Sincerely,
Carl
I would be grateful if you did it, but it would have to be said that
this is a post facto rationalization.
∂29-Nov-77 2309 TOB Workshop
John
The first day of the workshop was hands-on programming
in AL. Wed is discussion of issues, in Rm 74, Graduate
School of Business. Come if you choose.
I spoke to Chern with Feldman. No great revelations,
but the flavor is more science-oriented. He suggests
a fresh look at AL, a coherent program of basic research.
I am going for a separate development proposal to make
a PDP11 version of AL, and will try to go further, to
make an arrangement with Unimation for a collaboration
which would make AL available from Unimation.
Tom
∂30-Nov-77 0312 REM
You have a lot of files that haven't been referenced even once since the day
they were written in 1968, 1969, 1970... yet they remain on the disk. I
know you are the boss, but wouldn't those files be better off elsewhere?
All those super-old ones exist on at least two absolute-100%-complete-disk-dumps,
so rather than hassle with saving them on datacomputer perhaps they should
just be deleted considering they are already backed-up enough. With your
permission I could prepare a list of such files, for your inspection,
and delete them myself after your approval of the list (or some other
volunteer or student could). Your files currently occupy 2700 k of disk space,
and if we got rid of some really-useless stuff, it might actually put you
below your allocation, as well as freeup disk space for more active files.
I assume you haven't cleaned up your disk areas yourself because you've
been too busy working on your many important projects, that's why I
volunteered to have it done automatically (from your point of view).
Feedback on the general idea of auto-purge when files not referenced in
3 or more years? Feedback on auto-purge of your files in particular,
especially the ones you've totally forgotten about anyway and are just
in the way when you are looking for an active file whose name is similar?
My reason is different from what you suggest. I believe that the way to
go in the long run is that anything written by a person (as distinct from
a program) should be kept indefinitely. I had hoped that we would expand
disk file fast enough so that my starting in this mode wouldn't be a great
inconvenience, but I may have to take you up on your offer soon.
∂30-Nov-77 1234 FTP:Feinler at SRI-KL (Jake Feinler) NIC Questionnaire
Date: 30 Nov 1977 1238-PST
From: Feinler at SRI-KL (Jake Feinler)
Subject: NIC Questionnaire
To: jmc at SU-AI
cc: feinler
John,
Thanks for your input. I appreciate your taking
the time to fill it out.
Regards,
Jake
-------
∂30-Nov-77 2307 LES Student Research Assistantship
To: JB
CC: JMC, RWW, HVA
I am pleased to confirm that your research assistantship will continue at
least through the Winter Quarter.
∂30-Nov-77 2315 RWW memo
I have left a 1st draft of some FOL ideas in your mailbox for your comments.
rww
Thanks.
∂01-Dec-77 0939 100 : cr Phone Message
Thomas Cook Travels called and are still taking care of your trip so you
should call them.
∂01-Dec-77 1000 JMC*
CALL HERSCH
∂01-Dec-77 2000 MRC via AMET My move out here
To: LES, JMC, HVA
It appears that there was a moby ripoff irt my move (probably due to my
inexperience) and my stuff was weighed at much more than it should have
been. An investigator hired by Allied was over here and re estimated my
stuff and said that some people over in New York were being investigated
by the FBI and some were already in jail. It started when the
people here didn't like the reported weights they got and reweighed some
stuff and started checking back.
The upshot of all this is that Stanford is going to be getting some
money back. I knew these moving people were crooks but it is nice to
know there are some honest ones!
∂01-Dec-77 2125 AJT
In your mailbox is what I hope will be a close-to-final draft. I'd be
very grateful if you could spare the time to look it over, and give me
your estimate of how close it is to being satisfactory. I'll phone
in a few days.
Thanks. Arthur
∂02-Dec-77 1300 JMC*
mail to minsky
∂02-Dec-77 1315 FTP:MINSKY at MIT-AI (Marvin Minsky)
Date: 2 DEC 1977 1614-EST
From: MINSKY at MIT-AI (Marvin Minsky)
To: MINSKY at MIT-AI, HORN at MIT-AI, PHW at MIT-AI, DHT at MIT-AI
To: GLS at MIT-AI, BAK at MIT-AI, KLH at MIT-AI, HENRY at MIT-AI
To: jmc at SU-AI, binford at SU-AI, winograd at PARC-MAXC
To: bobrow at PARC-MAXC, rsmith at RUTGERS-10, amarel at RUTGERS-10
To: lefaivre at RUTGERS-10, hart at SRI-KL, nilsson at SRI-KL
To: reddy at CMU-10A, reid at CMU-10A, newell at CMU-10A
To: simon at CMU-10A
There is a pretty complete file about the QUASAR fake robot in
AI: MINSKY; ROBOT >. Near the end is a letter that McCarthy, Reid, and I
are planning to send to the "authorities". Please send your reactions
if strong, immediately, as I feel that such an action really comes
from this community and will reflect on it, one way or another.
-- Marvin Minsky
∂02-Dec-77 1505 FTP:Sacerdoti at SRI-KL (Earl Sacerdoti) Quasar robot & your letter
Date: 2 Dec 1977 1505-PST
From: Sacerdoti at SRI-KL (Earl Sacerdoti)
Subject: Quasar robot & your letter
To: minsky at MIT-AI, jmc at SAIL, reid at CMUA
cc: sacerdoti
I've read the correspondence and do have a strong opinion.
If the issue is basically a scientific one, it seems to me that
speculation about mechanisms whereby Quasar might swindle the elderly
is inappropriate. A letter to the Justice Department that is somewhat
more high-minded and more informational in intent might well be more
appropriate. Copies of such a letter should of course go immediately
to those in the press that have printed the Quasar claims as news,
though I'm sure it'd have less play than one raising images of little
old ladies being bilked out of thousands of dollars. Otherwise, I can
foresee the headlines: "QUASAR WARS: Robot Maker to Fight Scientists
over Libel."
-------
∂02-Dec-77 1522 FTP:Brian K. Reid <BR10 at CMU-10A> Quasar letter
Date: 2 Dec 1977 1816-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: Quasar letter
To: Sacerdoti at SRI-KL (Earl Sacerdoti)
CC: Minsky at MIT-AI, JMC at SAIL
In-Reply-To: Sacerdoti's message of 2 Dec 77 15:05
Experience has shown that very few people have the technical
background to smell the hoax surrounding the robot. Though we in the
computer science community didn't wonder whether it was a hoax but
how the hoax worked, it appears that the vast majority of the
country, even the non-CS scientific community, is quite ready to
believe that this robot is for real.
One of our people observed the other day, "Even though most Americans
don't seem to believe in God, that doesn't eliminate their need for a
savior. This robot looks like a savior. People don't want to
believe that it is a hoax." Very much to the point. Letters to the
press are not the answer; the public just won't believe it.
I think the issue should not be so much whether the letter
πonstitutes libel (given that only we three who signed it would be
liable), but whether it besmirches the AI community. Further, as
sent to the Justice Department, I don't think that the letter
constitutes libel. If it were sent to the New York Times, it might;
but sent to the Justice Department, it does not.
I suspect, actually, that if we stall much longer, the letter will
not be needed. When the Business Week article comes out, the jig
will more or less be up. The New York Times has put a reporter on
the story (he called me Tuesday; I suspect he's called others of you
before or since).
Brian
∂02-Dec-77 1559 RPG NCOMPLR
To: MACLSP.DIS[AID,RPG]:;
The Compiler has been adjusted to allow constructs of the
form (DECLARE (FASLOAD ... )). This was not allowed in earlier versions
since the .fas output was done on the same channel as fasload's.
This output is now done on channel 7, whereas fasload's are done on
channel 6.
-rpg-
∂02-Dec-77 1843 FTP:AMAREL at RUTGERS-10 letter to justice department
Date: 2 Dec 1977 (Friday) 2142-EST
From: AMAREL at RUTGERS-10
Subject: letter to justice department
To: minsky at MIT-AI, jmc at SU-AI, reid at CMU-10A
cc: LEFAIVRE, RSMITH, AMAREL
your letter to the justice department regarding the QUASAR fake robot is fine.
saul amarel
∂03-Dec-77 1426 LES
∂03-Dec-77 0859 JMC
Why can't we have telephone numbers for all users?
[Obviously we can. We haven't insisted and, for a number of peripheral
users such as random CS grad students, it is not clear to me that this
is worth doing. A related problem is that address and telephone data
seem to get out of date quickly, especially for grad students.
One thing that I plan to do soon that will help is to write a program
for extracting this information from new people and for making changes.
This program will mail the results to the supervisor (if a new account)
and/or to me for checking before insertion into the main file.]
It now occurs to me that the department might to the work of
keeping a complete file up-to-date now that the department is
using the machine.
∂03-Dec-77 1823 RPG Maclisp Manuals
To: JMC, LES, DCL, TOB, DCO
CC: RPG, WLS, JP, CGN, PAM
The subject of Maclisp Manuals has come up once more, this time in
the form of a rumor about them almost being presentable from MIT (i.e. PUBable).
I have sent some feelers into the brink there and have also fielded some
suggestions locally about the desirability of a chapter in that manual on
local features (of which there are quite a few). This latter adventure would
take a bit of time, and I wonder if enough local (moral) support can be
mustered for the effort. In any case, the issue is will there be (green)
support for obtaining/publishing a number of these manuals when available?
-rpg-
Maclisp manuals are needed for CS206 (Fall and Spring) and should be
in bookstore for general LOTS use. The lab should also invest.
∂04-Dec-77 0057 LES
∂04-Dec-77 0054 JMC
To: RPG, LES
Maclisp manuals are needed for CS206 (Fall and Spring) and should be
in bookstore for general LOTS use. The lab should also invest.
[Do you have any preference between buying from MIT and printing ourselves
(assuming they do no object)].
Also, did Lowell Wood call you in the last day?
No immediate preference, but M.I.T. has been known to overcharge for
some services. Also there is the local supplement RPG referred to.
Wood didn't call - at least not here. Perhaps there's a message on
my door?
∂04-Dec-77 0114 LES
Only a phone call from Thomas Cook travel.
∂04-Dec-77 1420 LCW S-1 Architecture Document
To: LES, JMC, BH, JBR, REG, ME, TED
CC: LCW
I have left a preliminary copy of the new S-1 Architecture Document
in each of your mailboxes, except that I left REG's in LES's mailbox.
I would like LE∃`to forward one copy to REG, please.
Curtt
∂05-Dec-77 0027 MRC DIALnet mail
To: JMC, LES
Please read MAIL.PRO[DLN,MRC], in particular page 5 about syntax. It is
critical before I go any further on these ideas that I talk to you
(especially JMC) about this syntax description. I am not a LISP hacker,
while I understand the concepts and have written programs in it, I am
somewhat vague in trying to explain it to others.
Once that's out of the way it's just a matter of selecting names.
Incidentally, somebody at LOTS is writing a new mail system, and he wants
to use DIALnet-format for the mail structure; it's a queueing mailer so
it's invisible to users, but I convinced him how much of a win S-expressions
are and so he's eager to go on this. So I want to push ahead on this asap.
[Mark]
∂05-Dec-77 0115 MRC
∂05-Dec-77 0109 JMC Three comments
1. The actual parentheses in the S-expressions could be replaced
by some less frequent ASCII codes if that would be a convenience.
YEAH, I SORT OF AGREE. BUT I DON'T THINK THAT MUCH BANDWIDTH
IS LOST BY /( AND /) AND // AND OF COURSE USING PARENS MEANS
IN THEORY AT LEAST BEING ABLE TO USE A REAL LISP AS THE READER!
2. Perhaps I'm thick or lazy, but I need some examples of use to understand
the proposal.
OH SURE. IT DOESN'T ALLEGE TO BE ANYWHERE NEAR COMPLETE. BUT I
REALIZED IN DEFINING S-EXPRESSION AND ATOM THAT I WAS OUT OF MY
FIELD, AND SINCE YOU ARE THE "INVENTOR" OF THE LANGUAGE...(!)
3. The compatibility-noncompatibility with ARPA issue needs to be
treated in more detail. The critics will smoke out your reasons
sooner or later, so why not now?
SURE, SAME AS #2. I'M BOUND TO BE ROASTED ALIVE NO MATTER WHAT
I SAY ANYWAY BY SOMEBODY.
∂05-Dec-77 0901 FTP:RSMITH at RUTGERS-10 QUASAR
Date: 5 Dec 1977 (Monday) 1158-EST
From: RSMITH at RUTGERS-10
Subject: QUASAR
To: jmc at SU-AI
(1) I have called QUASAR several times asking for an appointment.
I have used the Trojan horse that we are "local" New Jersey people
who want to make an unbiased appraisal of their technical prospects,
rather than relying on "foreign" assessments. So far this has
not gotten us in, although they promise that it will "when the robot
is in town". Currently, it is said to be busily playing engagements
on the West Coast.
(2) There is an article in this morning's NY Times, in the
financial section. It quotes you and Minsky, as well as quoting
very vehement comments by Reichelt. I am sending you a copy of
this by US mail.
Regards,
Bob Smith
I get the New York Times, and saw the dispatch on the NYT News Service
in the computer. Minsky and Brian Reid and I have written the Justice
Department and the Chief Postal Inspector. The letter is JUSTIC.LE1[LET,JMC].
However, this fact should not get in the newspapers as they should
have a clean field for investigation if they decide to do something.
I plan no further activity at present but will be interested in
what you turn up. What Reichelt says seems to be a random variable.
Note that he told Kleinfeld (NYT) that he has 32 of them, so are they
all on the West Coast.
∂05-Dec-77 1121 RWW
do you have a version of missionaries and cannibles on line?
∂05-Dec-77 1107 100 : cg quals etc
I thought I'd confirm the revised qual plans: my qual will be held at
11 am this coming saturday (the 10th). If I recieve no message to the
contrary I'll show up at the lab at the above mentioned time. Also,
I'm very sorry to have missed the party you gave for Jack Schwartz. Due
to my failure to inform the lab of my new address, the invitation arrived
after the party had taken place.
∂05-Dec-77 1134 RWW
by the way have you read the thing on FOL
∂05-Dec-77 1444 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
PLEASE NOTE: SEMINAR TOMORROW 6TH DECEMBER IS CANCELLED
VERIFICATION GROUP SEMINAR TUESDAY 13 th. DECEMBER
PLACE: ERL 237
TIME: 2:30 pm.
TITLE: To be announced
SPEAKER: NORI SUZUKI
*********************************************************
Please note that the time is back to 2:30 so all can attend
∂05-Dec-77 1621 JMB LOTS
To: JMC
CC: JLH, feigenbaum at SUMEX-AIM, DPB
I am quite upset about the LOTS situation. It has been many weeks since
assurances were made about terminals, limiting usage, alternative
computing sources, etc and little tangible progress has been visible
for the immediate and not too distant future. I am faced with (several)
students that flatly state that they will take the compiler course, CS240a,
IFF IT IS NOT DEPENDENT ON LOTS USAGE. Is there any ray of
sunshine in this situation that I have not been informed of, or should
we not (at last) consider it time for more drastic measures???
....Jeff Barth
On Thanksgiving weekend, which was the biggest jam, six more terminals
were got working. Another ten will go in over the vacation, possibly
sooner.
∂05-Dec-77 1658 DCL SEMINAR ON RUNCHECK
To: GROUP.DIS[VCG,DCL]:;
Steve German is now ready to give a very well organized talk with slides
on RUNCHECK, as aprelude to POPL.
This has to take place next week Please suggest times to DCL
∂05-Dec-77 1907 MFB phone
my phone number: 996-2569
mfb
∂05-Dec-77 2300 DPB LOTS
To: JMB
CC: JMC, feigenbaum at SUMEX-AIM
Jeff, I think that using SCIP is entirely out of the question.
I can check into the budget, but I don't think that SCIP is the
solution. I am beginning to become concerned about the amount
of criticism which LOTS is suffering. I think that LOTS has been
a remarkably successful resource this quarter. Who (not names,
but what sort) is making this "no LOTS in CS240" ultimatum? If
this is coming from our own PhD students, I can only assume that
they are being spoiled by the more restrictive research machines
which have been available to some. We used to get the same bitch
about 240 when it was done at SCIP. (i.e. SCIP is not a reasonable
medium for the compiler course, but for other reasons than the
LOTS bitch.) I'm willing to discuss this with those students who
are most negative about LOTS.
Here is the way I see the LOTS situation:
1.) The system has been running in a very reasonable way, providing
sufficient computing to users with reasonable response. It is now
end of quarter. I was on this afternoon, between 12 and 2. There
was one (about) 10 minute period during which the load ave. got over
12. The (lack of) response was annoying but not debilitating. A few
minutes later the load ave. was back down under 7 and the response
was quite decent. This is at the busiest time of the day, busiest time
of the quarter.
2.) The main problem from a user point of view is that terminals are
not available. There are sometimes long queues for terminals. The
queuing system seems to be working equitably. The first solution to
this problem which is being attacked is to get the additional ports
installed. Ralph has been working for the last couple of weeks on
debugging the new multiplexor. For twice the money, (or maybe worse),
the ports POSSIBLY could have been done by a more legitimate vendor
(like DEC) earlier during this quarter. Since LOTS budget is quite
tight, they are home-brewing the new ports. Thus, there have been
delays in delivering the hardware. It is hoped that there will be
about 70 ports available for Winter (compared with about 45 this quarter.)
If this happens in time, some of the terminal wait problems will diminish.
3.) Of course, as more terminals become active the machine will become
more loaded. The magnitude of this effect, however, is very hard to
anticipate. I optimistically think that the system will continue to give
annoying but livable response.
4.) You mentioned that somebody thinks that LOTS usage will be higher
next quarter. According to the above discussion, that seems to be
a reasonable conclusion. But that does not necessarily imply that
the quality of usage will diminish. That is, sure, more people will
be using more terminals. But the questions are, How long are the
terminal Q's? and How well does the system respond? I can give a rough
comparison of this quarter's CS courses with next.
Course #this quarter est# winter notes
---------------------------------------------------------------
CS105/6 ~200 ~200 no real change
CS107 0 ~60 big addition
CS111 ~100 ~100 no real change
CS103 ~100 ~100 no real change
CS104 ~50 ~50 no real change
CS140A ? ? no real change
CS140B 0 ? big addition
CS137A/B ~70 ~50 Small drop
CS135 0 ~60 Medium addition
CS144A/B ? ? probably small drop
CS206 ? 0 medium drop
CS240A 0 15 small addition
So overall the addition of CS07 and a section of CS140 will be the
main additions to the CS usage of LOTS.
General comments. I am unsympathetic to the "demand" that 240 not
be on LOTS. I am inclined to think that the issue is really one
of the convenience of LOTS not its usefulness. It would certainly be
"nicer" if we had a software laboratory, or a CS machine on which to
run the advanced courses. But I think that LOTS is adequate to handle
the demand in a reasonable, if inconvenient, way.
I agree that the next issue for the LOTS management to address (AFTER
the new ports are installed) is that of allocation of resources to
the various users.
I have not yet had one student come to me this quarter and claim
that they were unable to complete an assignment due to the unavailability
of the machine. In past quarters, using SCIP, this has happened regularly.
Some of this effect is a result of students being much more aware that
they cannot do their homework all on the last night. I thought at the
beginning of the quarter that this would be a big problem, but it hasn't
turned out that way.
Please excuse the rambling nature of this document. I composed it
entirely on the fly in one draft, and in haste. Comments, vehement
objections, etc. welcome. -Denny
P.S. In the past there has been very little computing done in 240A.
Most of 240A was theory of languages, and 240B was the project. Is
this expected to change drastically in your version?
Many thanks, Denny. There is some hope that next quarter be
easier anyway, besides the new ports, because in the SCIP regime,
the money spent on instructional computing declined monotonically
during the academic year, and last year we had most of engineering
in the Winter quarter and got by with a much smaller machine and
fewer terminals.
Incidentally, Jeff, I forgot to say that we have load shed. Namely,
text preparers can be bumped when there are more than 5 waiting for
terminals. On reading your message, I dashed over to LOTS at about
9pm and found 24 in the queue. By 11pm, the number waiting was down
to 5 and the wait was about 5 minutes. If it doesn't get worse than
that, we're all right, but I fear it will. I'll ask Ralph if we can't
get another few terminals without more down time than they are worth.
∂06-Dec-77 0653 MRC
∂06-Dec-77 0652 FTP:JZS at CCA Sam Strugglegear assails Boston
Date: 06 DEC 1977 0951-EST
From: JZS at CCA
Subject: Sam Strugglegear assails Boston
To: Header-People at MIT-MC
Bob Dornick of Quasar Industries and side-kick Sam, "programmed for
random conversation", appeared on the WCVB Good Day program this morning
and will be "chatting" with the folks at Jordan Marsh, Boston today.
/Joanne
-------
∂06-Dec-77 0841 MRC DIALnet mail
Sigh! With the system down and my having to stay up to make sure LOGIN
was working, I am now quite gronked. If I stayed around to talk about it
today, I will be quite incoherant, so I'm gonna go home and crash. Maybe
I'll be around later today. I have to be on day phase by Saturday, so
will see you during the day sometime soon about this.
[Mark]
∂06-Dec-77 0941 FTP:JZS at CCA Sam Strugglegear assails Boston
Date: 06 DEC 1977 0951-EST
From: JZS at CCA
Subject: Sam Strugglegear assails Boston
To: Header-People at MIT-MC
Bob Dornick of Quasar Industries and side-kick Sam, "programmed for
random conversation", appeared on the WCVB Good Day program this morning
and will be "chatting" with the folks at Jordan Marsh, Boston today.
/Joanne
-------
∂06-Dec-77 1008 CR Phone Message
Bill VanCleemput called and would like you to return his call at 7-1270
∂06-Dec-77 1050 DPB
To: JMC
CC: feigenbaum at SUMEX-AIM
John, I must find you an appropriate office in polya for winter quarter.
The building is nearly full, and in many cases over-crowded, now. I'd
like to impact the grad. student space as little as possible.
(Current stats: 27 offices. 9 offices house 9 staff members.
10 offices house 13 faculty members(and visitors). 8 offices house
30 students. and two of the student offices barely fit 2 desks.)
So, how much time do you plan to spend at Polya? Would sharing an
office be unreasonable? I will check with some other Polya occupants
to see what their plans are also. -Denny
∂06-Dec-77 1111 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 6 DEC 1977 1410-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
Dear John:
I think that you did a good job on the paper. What it needs now is input
from your colleagues in the development of LISP. What do you think of the idea
of sending a copy to each of them?
I liked your section on the micro-manual for LISP and
thought that it was particularly appropriate.
Below some utility functions are defined which will be used in the LISP
interpreters:
(defun bind←identifiers (identifiers values environment expression)
(cond ((null identifiers)
(cond ((null values)
environment)
(t (error '|Too Few Arguments| expression))))
((null values)
(error '|Too Many Arguments| expression))
(t (cons (list (car identifiers) (car values))
(bind←identifiers (cdr identifiers)
(cdr values)
environment
expression)))))
(defun lookup (identifier environment)
(cond ((null environment)
(error '|Unbound Variable| identifier))
((equal identifier (caar environment))
(cadar environment))
(t (lookup identifier (cdr environment)))))
(defun list←of←values (expressions environment)
(cond ((null expressions)
nil)
(t (cons (eval (car expressions) environment)
(list←of←values (cdr expressions) environment)))))
(defun eval←list (current←value expressions environment)
(cond ((null expressions)
current←value)
(t (eval←list (eval (car expressions) environment)
(cdr expressions)
environment))))
!
First define the evaluator which uses dynamic scoping:
(defun eval (expression environment)
(cond ((atom expression)
(cond ((numberp expression)
expression)
(t (lookup expression environment))))
((eq (car expression) 'quote)
(cadr expression))
((eq (car expression) 'lambda)
expression)
((eq (car expression) 'cond)
(eval←cond←clauses (cdr expression) environment))
(t (apply (eval (car expression) environment)
(list←of←values (cdr expression) environment)
expression
environment))))
(defun apply (procedure arguments expression environment)
(cond ((primitive? procedure)
(apply←primitive procedure arguments))
((eq (car procedure) 'lambda)
(eval←list (eval (caddr procedure)
(bind←identifiers (cadr procedure) environment expression))
(cdddr procedure)
(bind←identifiers (cadr procedure) environment expression)))
(t (error '|Unknown Procedure| (list procedure arguments)))))
(defun eval←cond←clauses (clauses environment)
(cond ((null clauses)
nil)
((eval (caar clauses) environment)
(eval←list 't (cdr clauses) environment))
(t (eval←cond←clauses (cdr clauses) environment))))
!
Now by changing the way that lambda expressions are evaluated
we obtain an interpreter which uses lexical scoping [like the lambda calculus of Church
and ALGOL-60]:
(defun eval (expression environment)
(cond ((atom expression)
(cond ((numberp expression)
expression)
(t (lookup expression environment))))
((eq (car expression) 'quote)
(cadr expression))
((eq (car expression) 'lambda)
(list 'closure (cdr expression) environment))
((eq (car expression) 'cond)
(eval←cond←clauses (cdr expression) environment))
(t (apply (eval (car expression) environment)
(list←of←values (cdr expression) environment)
expression))))
(defun apply (procedure arguments expression)
(cond ((primitive? procedure)
(apply←primitive procedure arguments))
((eq (car procedure) 'closure)
(eval←list (eval (cadadr procedure)
(bind←identifiers (caadr procedure)
arguments
(caddr procedure)
expression))
(cddadr procedure)
(bind←identifiers (caadr procedure)
arguments
(caddr procedure)
expression))
(eval (cadadr procedure)
))
(t (error '|Unknown Procedure| (list procedure arguments)))))
The definition of eval←cond←clauses is the same as above.
!
Note that if the version of eval that uses lexical scoping is adopted then
the procedures cons, car, and cdr need no longer be taken as primitives since
they can easily be defined as follows:
(defun cons (x y)
(lambda (message)
(cond ((equal message 'car)
x)
((equal message 'cdr)
y)
((equal message 'print)
(print '|(|)
(aprint x)
(aprint←sequence y)
(print '|)|))
(t (error '|Unknown Message| message)))))
(defun car (l)
(l 'car))
(defun cdr (l)
(l 'cdr))
(defun aprint (x)
(cond ((atom x)
(print x))
(t (x 'print))))
(defun aprint←sequence (l)
(cond ((null l))
((null (cdr l))
(aprint (car l))
(t
(aprint (car l))
(print '| |)
(aprint←sequence (cdr l)))))
!
ACKNOWLEDGEMENTS
The above interpreters are based on a very elegant one developed
by Jerry Sussman. The term "closure" is due to Peter Landin. The idea of
defining cons as given above is primarily due to Alonzo Church and Alan
Kay.
∂06-Dec-77 1923 FTP:STEIG at MIT-AI (Richard Steiger)
Date: 6 DEC 1977 2224-EST
From: STEIG at MIT-AI (Richard Steiger)
To: bpm at SU-AI, jmc at SU-AI
Now that you mention it, presumably poor old Reichelt probably never even said
..."God help me, etc."
----Minsky
∂06-Dec-77 1947 FTP:HENRY at MIT-AI (Henry Lieberman)
Date: 6 DEC 1977 2236-EST
From: HENRY at MIT-AI (Henry Lieberman)
To: jmc at SU-AI
We tried to get somebody to go, but I don't think
anybody did. We learned of the Boston appearance too late
and couldn't get to its subsequent appearance in a distant
suburb because of a snowstorm.
∂06-Dec-77 2040 AJT
My reading committee is you, Roger Shepard and Bruce Buchanan. Both of the
latter seem satisfied with the current state of things. So, it's rather up to
you...
What is your current address and telephone number?
∂06-Dec-77 2335 DCL
To: GROUP.DIS[VCG,DCL]:;
Vote so far for SMG's RUNCHECK talk is WED 14th at 2.00pm;
please send alternate suggestions to DCL.
∂07-Dec-77 1115 JMC*
S-1 to Jim Gray
∂07-Dec-77 1409 RAK
To: JMC, LES
∂07-Dec-77 1305 LES Phoney robots
Do you know any trouble-making Caltech students or others in the L.A. area?
The phoney Quasar robot is scheduled to make two appearences in May Co. stores
there tomorrow: 10am at Laurel Plaza and noon at Fox Hills.
It might be fun if someone invited the media and called attention to the
remote controllers. Or better yet, jammed their radio link.
[
I called Jim Black at Caltech; he said he would see if anyone is interested.
Dick
]
∂07-Dec-77 1422 FTP:Feigenbaum at SUMEX-AIM Re: REMINDER...REMINDER...REMINDER
Date: 7 DEC 1977 1422-PST
From: Feigenbaum at SUMEX-AIM
Subject: Re: REMINDER...REMINDER...REMINDER
To: Levin
cc: jmc at SU-AI
In response to your message sent 7 DEC 1977 0905-PST
Laurie, please arrange for John McCarthy to go the Dean's emergency
meeting on Dec. 9.
Ed
-------
∂07-Dec-77 1442 FTP:STEFFERUD at USC-ISI Re: Quasar
Date: 7 DEC 1977 1437-PST
Sender: STEFFERUD at USC-ISI
Subject: Re: Quasar
From: STEFFERUD at USC-ISI
To: JMC at SU-AI
Cc: uncapher, stefferud
Message-ID: <[USC-ISI] 7-DEC-77 14:37:30.STEFFERUD>
In-Reply-To: Your message of DECEMBER 7, 1977
Very Interesting John!
I believe those are in Kieth's territory. I am in Huntington
Beach, way down in Orange County. Do you have information
regarding their appearance down here, like maybe at the
Westminster Mall?
Of course, I realize that the LA Times may not be involved down
here, but local papers might be.
Best - Stef
-------
∂07-Dec-77 1543 FTP:STEFFERUD at USC-ISI FYI [JMC at SU-AI (John McCarthy): Quasar]
Date: 7 DEC 1977 1450-PST
Sender: STEFFERUD at USC-ISI
Subject: FYI [JMC at SU-AI (John McCarthy): Quasar]
From: STEFFERUD at USC-ISI
To: LA-TYPE-FOLKS:
Bcc: JMC at SU-AI, Uncapher at ISIB
Message-ID: <[USC-ISI] 7-DEC-77 14:50:39.STEFFERUD>
Begin forwarded message
--------------------
Mail from SU-AI rcvd at 7-DEC-77 1257-PST
Date: 7 Dec 1977 1255-PST
From: JMC at SU-AI (John McCarthy)
To: uncapher at USC-ISI, stefferud at USC-ISI
Subject: Quasar
The Quasar "robot" will be at the May Company store at Laurel Plaza
at 10am tomorrow and will be at the May Company Fox Hills store at
noon (both in the L.A. area). The L.A. Times, (reporter Steve Harvey),
will be looking for evidence of remote control.
-------
--------------------
End forwarded message
-------
∂07-Dec-77 1546 FTP:STEFFERUD at USC-ISI Content of LA-TYPE-FOLKS: list
Date: 7 DEC 1977 1454-PST
Sender: STEFFERUD at USC-ISI
Subject: Content of LA-TYPE-FOLKS: list
From: STEFFERUD at USC-ISI
To: jmc at SU-AI, Uncapher at ISIB
Cc: Stefferud
Message-ID: <[USC-ISI] 7-DEC-77 14:54:17.STEFFERUD>
I extracted from the <msggroup>mailing.list to get the following -
LA-TYPE-FOLKS:,
@BBNA, Myer, Vittal,
@CMUA, Brian.Reid,
@ECL, Caine, Carlisle, EKGordon,
@ISIA, PBaran, DCrocker, Farber,
@ISIA, Spivey, Stefferud,
@ISIB, JimC, Cohen, Ellis, Holg, Postel, Stotz,
@PARC-MAXC, Brotz, McDaniel, Metcalfe, Schlesinger, White,
@RAND-UNIX, BRD, Gaines, Greep, MLW, Anderson, WEC,
@SU-AI, DGR,
@UCLA-SECURITY, Mark, Lauren, Rudisin, Steve
-------
∂07-Dec-77 1620 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 7 DEC 1977 1920-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
CC: CARL at MIT-AI
Dear John,
Did you receive the interpreters that I sent you by netmail?
If you like them I can annotate them with comments or you can do that
yourself if you prefer.
Jean has sent a nice letter of invitation to Stoyan for him
to be a discussant for your lecture! You should receive a copy of
the letter via U.S. mail in a couple of days.
When you come to M.I.T. next time I would like to demonstrate our
implementation of PLASMA to you. It is based on the actor message passing
semantics which we have developed and is a large improvement over
MICRO-PLANNER. Unfortunately we don't have a manual for it yet but plan to
have one by next spring.
Sincerely,
Carl
I'll read the interpreters tonight. Please thank Jean for me. Of course,
Stoyan probably won't come, and wouldn't have been able to come, no
matter what anyone did. The Stoyan strategy, as with all proposed
visitors from socialist countries, is to relax, and let them do the
worrying about whether they will come. We should have a modest fall-back
position, like eliminating him as a discussant, or subsituting yourself,
when and if it becomes clear, up to the day of his arrival in the U.S.,
that he can't come.
∂07-Dec-77 2059 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 7 DEC 1977 2359-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
CC: CARL at MIT-AI
Dear John,
I will thank jean for you and would be happy to be the backup discussant
in case Soyan can't make it to the conference.
Sincerely,
Carl
∂07-Dec-77 2138 FTP:STEFFERUD at USC-ISI [Dcrocker at Rand-Unix: Quasar Quack...]
Date: 7 DEC 1977 2132-PST
Sender: STEFFERUD at USC-ISI
Subject: [Dcrocker at Rand-Unix: Quasar Quack...]
From: STEFFERUD at USC-ISI
To: jmc at SU-AI
Message-ID: <[USC-ISI] 7-DEC-77 21:32:44.STEFFERUD>
Begin forwarded message
--------------------
Mail from RAND-UNIX rcvd at 7-DEC-77 1611-PST
Date: 7 Dec 1977 at 1609-PST
From: Dcrocker at Rand-Unix
To: Greep at Rand-Unix
Cc: Anderson at Rand-Unix, Gaines at Rand-Unix, Norm at Rand-Unix,
Grm at Rand-Unix, Cas at Rand-Unix, Farber at Rand-Unix,
Dcrocker at Rand-Unix, Uncapher at Isi, Stefferud at Isi
Subject: Quasar Quack
Re: [fyi]
In-Reply-To: Your Message of 7 Dec <[Rand-Unix] 7-Dec-77 15:25:11.Greep>
Message-ID: <[Rand-Unix] 7-Dec-77 16:09:56.Dcrocker>
I live near Fox Hills and will go to the demo. Dave.
--------------------
End forwarded message
-------
∂07-Dec-77 2132 DGR via NBST HSTHST.PRO
To: MRC, JMC, LES
Thanks for pointing me to this file.
My offer of cooperation with Dialnet was (and is) of dual form:
o As head of the DECUS Networks and Communications Working Group
I would have been (and still would be) happy to see if enough
interest exists in DECUS to form a project committee thatyou could
use as a sounding board or for other purposes. If nothing else,
it would publicize the Dialnet effort among the non-ARPAnet DECUS
community and possibly prevent non-orthogonal efforts.
o I am personally interested in Dialnet both on an intellectual basis
and because Keith Gorlen and I at NIH have completed a rather
elaborate DEC-10 to/from PDP-11 (RSX-11M&RT-11) file transfer
package we call CLINK that uses full-blown DDCMP and DAP over
asynchronous telephone line.
The specific comments I have on first reading are:
1. No specific provision is made for re-establishing lost bit
synchronization. Once bit synchronism is lost (perhaps due to line noise)
the ability of the receiver to eventually re-establish correct framing
depends on the degree to which a receiver responds to a "space" signal
during the stop bit and the patterns of the data. For example, most
UARTs declare a "framing error" if the "middle" of the stop bit and will
not readjust until some time after that sample . (Previous line
should say "of the stop bit is a space".) Re-syncing on data that has lots
of logical 0 bits is difficult, and the protocol has lots of them (the
reeserved value after SOP, OP-codes with low numbers, 0-socket nuymbers, etc.)
In CLINK we found that communications over an async line was greatly helped
by sending DEL (377) before the equivalent of SOP when re-transmitting
an item. The DEL re-establishes any possible lost bit sync.
2. Quoting with SOP. You should probably note that some chars
(all those which are legal after SOP, currently only a 000, but I don't know
what you are planning for that reserved byte) MUST NOT be quoted.
3. Clarify "out of sequence" errors. Say the receiver has just received
#5 and then gets a non-SOP. Assuming the SOP has been dropped or
clobbered, the receiver may send ERR #6 with code tht says non-SOP
received. Say the non-SOP is due to a line hit (which we observe
usually generates a lower-case y, vertical bar, or or DEL).
Then #6 may be received correctly because the sender starts and finishes
it before he processes the ERR #6. The sender, seeing ERR #6, retransmits
it. Since #7 is now expected (or even higher due to the window), #6 when
received is out of sequence which generates another ERR #6 (out of sequen ce).
A sender which really believes the message is out of sequence can perpetuate
the error by sending #6 again, or possibly decide that all msg # synchronism
is lost and reset. In CLINK we stopped this one in two ways: anything
not beginning with the equivalent of SOP is ignored (no ERR); the timeout
takes care of the retransmission if needed; and, the receiver does not
complain about a duplicate message (just tosses it quietely).
I suggest that the protocol be clarified in any one of several ways
which will prevent an interpretation which leads to trouble.
4. Additional allocations in ACKS. There are several characteristics of the
"additional" allocation scheme that are not clearly wins. It will and
does work.. The receiver must remember a "window-size" of the additional
allocations sent back with ACKs in case the ACKs must be retransmitted.
(Note that a bad ACK will possibly generate a "sequence error" depending
on the interpretation of what a sequence error is.) The receiver cannot
ever rescind or reduce the allocations sent to the sender without some
interesting definitions of signed quantities (are they intended to be signed?)
Vince Cerf at DARPA is working on internetting protocols and is pushing
the concept of "highest byte number" instead (and possibly to be submitted
as part of an ISO standard). Each side numbers their bytes and
the highest byte number that will be acceptable is sent with the ACK.
Perhaps worth thinking about.
5. 5 second ACK timeout. If I interpret correctly what has scrolled off
my screen, ACKs are repeated in 5 seconds if a new msg is not received. The NOP
also has a 5. second timeout. Perhaps these two timeouts should be different so that
we don't get into the situation where both a NOP and an ACK is sent each 5. seconds.
(No harm done, but error counters would record an event (had to repeat the ACK)
that wasn't really an error.)
My best . . . Glenn
∂07-Dec-77 2344 MRC irt your message on Pearl Harbor Day, 1977
To: DGR
CC: JMC, LES
Glenn,
Thanks much for your kind and well-thought out letter. Much of it
is quite useful, but some reflects things that I have failed to
make clear or incomplete changes. I will try to answer each point.
1. I expect that the "official" DIALnet modem will handle bit
synchronization. I look forward to the super-hairy DIALnet modem
which will do SOP synchronization instead of the interrupt level
part of the DCP having to worry about that.
2. You have caught a real bug. The prattle about the op-codes
with values corresponding to the values of SOP and EOP being illegal
should be no-op'd. Originally the op-code and the "reserved" byte
were in the opposite order and were swapped at the suggestion of
some Bell Labs peopl who said that would make the host-host protocol
exactly like an existing line protocol in use (in Canada I think;
I'm not sure).
2a. That secret "reserved" byte is for channel number, of course.
I want it, but Les is opposed to it ("over my dead body"). In order
to prevent infinite hurt feelings we compromised on the reserved
byte, and I implemented it in a way that if I am right and multiple
channels become a reality, a smart multi-channel guy can talk to a
cretin single-channel guy and win only using channel 000--the smart
guy can figure out he's talking to a cretin by getting an "attempt
to connect process when a connection exists" error; so everybody
will win as much as possible, assuming the implementors of the
protocols obey what I say in the document and don't do something
silly with that byte.
In any case, it isn't a secret; that's what that byte is officially
before, but that feature is officially non-existant. Rather than
arguing endlessly about it I figured it would be better to wait and
see...
3. Out of sequence does not include redundant packet, ie, a packet
within the window can be repeated. That's why the window is
limited to 176 and not 177 or higher. I am going to consider this
further; perhaps your idea is better.
4. This has been a problem (about allocation with ACK). I am on
the verge of flushing it. Unless somebody says to keep 'em, they
will be flushed soon.
5. ACK timeouts and all timeouts were really picked rather randomly
I'm afraid. I hope to do some tuning on this first so I know what
good values are.
Thanks a lot for your help. I am editing the document now to take
care of some of your problems, and am considering the others. I
hope to hear from you again.
Regards,
Mark
∂08-Dec-77 1415 FTP:PRATT at MIT-AI (Vaughan Pratt)
Date: 8 DEC 1977 1655-EST
From: PRATT at MIT-AI (Vaughan Pratt)
To: rem at SU-AI
CC: (FILE [PRATT;LISP MAIL]) at MIT-AI, jmc at SU-AI
The next language I design or get involved in the design of will separate
competence from performance to a greater degree than is presently done by any
practical languages to date, and to a greater degree than is done by RLPL.
Programs will consist of the "basic algorithm," which a human may be able to
translate into efficient machine language using considerable ingenuity, more
than it would be reasonable to expect of even the cleverest optimizers John
Cocke can produce. In addition to the basic algorithm programs will have much
implementation advice in a formal language for giving such advice. The
programmer will use his ingenuity (or his strong intuitions about how to write
machine code) to generate that advice, and the compiler will know how to take
advice. The basic algorithm is the competence, the advice is the performance.
JMC would approve, I think. (In fact, I'll cc this to him now.)
The language for the basic algorithm will be able to name objects of various
interesting types; ground types such as numbers and booleans, and higher types
constructible using sum and product. (Sum means disjoint union of types, product
means Cartesian product. Functions fit into this as powers, i.e. exponentiation,
so that the type A→B is the A-th power of B, that is, the product of B with itself
"A times," which makes sense if you think of a function as an A-tuple of elements
of B, that is, a tuple whose coordinates are the elements of A. Think of such a tuple
as a table giving the values of the function. This is the way functions of higher
type have to be thought about if you want to do induction on objects of any type
you can name in your programming language, which is essential to proving the
correctness of programs that work with objects of such types. I claim that
thinking about one's data structures within such a framework gives the cleanest
way to understand what one's complex-data-types are formally.)
I have yet to do any work on the performance language. I consider this an
excellent area for a Ph.D. thesis.
∂08-Dec-77 1446 FTP:Geoff at SRI-KA (Geoffrey S. Goodfellow) VADIC 3467.
Date: 8 Dec 1977 1445-PST
Sender: GEOFF at SRI-KA
Subject: VADIC 3467.
From: Geoff at SRI-KA (Geoffrey S. Goodfellow)
To: JMC at SAIL, LES at SAIL
Cc: MRC at SAIL
Message-ID: <[SRI-KA] 8-Dec-77 14:45:50.GEOFF>
Vadic has just announced the VADIC 3467, which combines data sets
from bell and VADIC by automatically recognizing data recienved
from a Bell System 103 [300 baud type ], Bell System 212 [1200
baud type] and VADIC 3400 [1200 baud type] modems.
THe Automatic recognition sequence that identifies an incoming
signal to the VA3467 operates under microprocessor control and
noes not disturb norman connect protocols for and specific modem.
The was announced on the front page of the Nov 14 '77 edition of
Computer World. If you can't get ahold of it, I'll be glad to
give you a xerox of the artical.
-------
∂08-Dec-77 1859 JMC*
vera message
∂09-Dec-77 0115 MRC
To: JMC
CC: JBR, LES
∂08-Dec-77 2151 JMC new telnet
To: MRC
CC: JBR, LES
If the commands of new telnet are not as presently documented in
the Monitor Manual, then I object.
They are essentially the same. The differences are mostly in features
that are unused. A user using TELNET from the manual will be screwed
since the manual is grossly out of date for the current TELNET.
I have several users using the new program and there are no complaints
that have not been fixed or satisfied. Except for the Datamedia
simulator of the old TELNET (which is currently unused due to several
problems in it) the new program is a grossly superior product. My
intent is to have my new program run by TELNET and TN, and the old
program run by OTELNET (or OTN) in case problems arise. -- mrc
∂09-Dec-77 0409 MRC Allocations in ACKs
To: JMC, LES
Have been flushed. As a result, I seriously suggest that 4800/150 modems
be flushed as an idea because the bandwidth difference is too great to be
able to run at full speed at 4800, even assuming maximal packet size!
Geoff suggested data compression, which I consider should (or rather MUST)
be made available as an option. I think something like DCMAIL and DCFTP
should exist; that follows my policy of letting cretins and winners win;
ie, a winner tries DCFTP before FTP, and a cretin simply refuses to allow
DCFTP. I will be away tommorrow and Saturday during the day; however I
will be in later tommorrow and probably all day Sunday. After that I think
I will be in night mode again.
∂09-Dec-77 1057 CR Phone Message
Please return call (collect) to Victor Sanchez, Mexico City, 531-8439.
905
∂09-Dec-77 1101 FTP:SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
Date: 9 DEC 1977 0942-EST
From: SIRBU at MIT-MC (Marvin A. Sirbu, Jr.)
To: jmc at SU-AI
Thank you for giving me the opportunity to interview you during my
recent trip to California. The information you have provided will be of
considerable value in our assessment of the future of electronic mail
systems.
I will be happy to send you a summary of our findings upon com-
pletion of the study at the end of February. Many thanks again for
your cooperation.
Sincerely,
Marvin Sirbu
∂09-Dec-77 1213 DPB Spring AI courses
To: JMC, CCG
John and Cordell,
Here is my view of the plans for the Spring AI courses.
CS224 JMC TTH 1:15-2:30
CS206 CCG TTH 11:00-12:15
CS229 CCG When? (This is the Advanced AI Programming course.)
We need a time for CS229 when its convenient for CCG but doesn't confict.
Since 2:30-3:45 is reserved for faculty meetings, that only leaves 9:30-10:45
on TTH. This would mean CCG teaching 9:30-12:15, which might get nasty.
There is some sentiment about changing the timing on CS224
because it conflicts with 246 (Operating Systems), and both
are useful for Comprehensive.
You might consider MWF, but I know that both of you prefer TTH. See what
you can work out. Time schedule due Monday. -Denny
I am agreeable to changing 224 to any time that is not early in the
morning. I don't mind MWF for this course.
I take it back about not minding MWF. I would like CS224 to have the
same total number of lectures as last year, since it is based mainly
on guest lectures, and I want about the same scheme as before.
∂12-Dec-77 0000 JMC*
Kreisel
∂12-Dec-77 0118 MRC US/Mexico prisoner exchange
"...anything but an even swap. The 36 Mexican prisoners who returned
to Mexico on Friday were the only ones out of 1,200 in U.S. jails willing
to return home."
Which goes to prove: if yer a wetback and ya don' wanna git deported,
go to jail!
∂12-Dec-77 1100 JMC*
send pnueli concep and know
∂12-Dec-77 1100 JMC*
call Buchanan about Thomas thesis.
I am inclined to sign off on Arthur Thomas's thesis. I don't agree with
its philosophy, but he is unlikely to change it, and I think he has
done enough work. What is your opinion?
∂12-Dec-77 1117 FTP:Brian K. Reid <BR10 at CMU-10A> LA robot visit
Date: 12 Dec 1977 1415-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: LA robot visit
To: JMC at SU-AI (John McCarthy)
In-Reply-To: John McCarthy's message of 7 Dec 77 12:55
Did the LA Times and Steve Harvey come through?
I know of nothing and don't see the L.A. Times.
∂12-Dec-77 1138 TOB student
Prof H.H.Nagel, Universitat Hamburg, has
written requesting that a very good student
join our group for one year starting September
on a German fellowship. Prof Nagel has been
doing good work in vision and I expect that
this is a good venture. I want to invite him
with a letter which states that he be entirely
supported by the German fellowship.
Tom
∂12-Dec-77 1208 CCG cs229
The advanced ai programming techniques course is on for the spring. Hope
to cover how to compile pattern matchers,how to do unification, production
rule systems, saving space in a theorem prover by storing only modifications
to expressions, use of hash consing, comparison of interlisp and maclisp,
advanced language features in each, multiprocessing in lisp, list structure
entropy and compression, incremental and linearizing garbage collection,
funargs,symbolic interprters,and a host of other scattered but useful lore.
DPB said you were curious if it would happen and what it might cover.
Cordell
∂12-Dec-77 1315 DPB Spring Class schedules
To: JMC, CCG, taynai at SUMEX-AIM
It looks like the best solution is
9:30 CCG CS206
11:00 JMC CS224
1:15 CCG CS229
If I don't hear objections this is the way it will go in. -Denny
The above solution also removes the conflict between CS224 and CS246.
JMC said that he didn't mind moving, but not MWF, and not early morning.
CCG said below.
∂12-Dec-77 1159 CCG schedule
I definitely want tuesday and thursday for both classes. It is also a good idea
to have a break between them. So 11 and 1:15 is ok. also 9:30 and 1:15 is ok.
9:30 and 11 is rather challenging, but may be possible.... I want 206 first
since it is a little less tiring.
Don't depend on me geting net mail.
Cordell
∂12-Dec-77 1348 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR TUESDAY 13 th. DECEMBER
PLACE: ERL 237
TIME: 2:30 pm.
TITLE: Verification Decidability
SPEAKER: NORI SUZUKI
*******************************************************************
Please note that the time is back to 2:30 so all can attend
∂12-Dec-77 1356 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR WEDNESDAY 14th. DECEMBER
PLACE: ERL 237
TIME: 2:30 pm.
TITLE: Automating Proofs of the Absence of Common Runtime Errors
SPEAKER: STEVE GERMAN
*******************************************************************
This is a special end-of-quarter seminar:
Please note that the time is back to 2:30 so all can attend
∂12-Dec-77 1513 FTP:Hart at SRI-KL (Peter Hart) ( Forwarded Mail )
Date: 12 Dec 1977 1514-PST
From: Hart at SRI-KL (Peter Hart)
Subject: ( Forwarded Mail )
To: JMC at SU-AI
Date: 12 Dec 1977 1511-PST
From: Hart
Subject: Help on something important
To: Duda, Nilsson, Raphael, Sacerdoti, Tenenbaum,
To: Feigenbaum at SUMEX-AIM, McCarthy at SAIL, Newell at CMU-10B,
To: Reddy at CMU-10B, Horn at MIT-AI, Minsky at MIT-AI,
To: Winston at MIT-AI, Amarel at RUTGERS-10, Uncapher at ISI,
To: Buchanan at SUMEX-AIM, Winograd at SAIL,
To: Woods at BBN-TENEXD, Anderson at RAND-UNIX
cc: Hart
As you may know, a study is being established to "forecast technology
which will drive military weapon systems for the rest of this century."
The study, which spans a broad range of disciplines, has been
specifically requested by a triumvirate consisting of Bill Perry,
Frank Press, and Stan Turner, and will therefore be visible to high
R&D policy-making levels.
I have agreed to be responsible for the section of the study
dealing with artificial intelligence. In view of the potential impact
of the forecast on longer term trends in R&D funding, it seems to me
important that it reflect the ideas of the AI community, not merely
the idiosyncrasies of one individual. Accordingly, I am asking for
your help in formulating a set of technological possibilities and,
if circumstances permit, your help in reviewing the document produced.
The ground rules of the study are that it is to focus on technological
opportunities, rather than on the likely future course of current
efforts under a "business as usual" scenario. It is important that
the relevance of these opportunities for national security be
identified as firmly as possible.
I would like specific suggestions organized under two broad classes:
Technological developments-- What improvements in AI
technology are possible over the next 20 or so
years-- for example, language understanding
sufficient to comprehend the AP wire, vision
capable of understanding any ordinary office
scene, etc. Annotations dealing with your
assessment of the degree of risk, time scale,
intuitive arguments or supporting evidence for
your candidates, etc., would be very helpful.
Systems developments-- What AI-based systems of military
significance are possible over the next 20
years. These may depend on one or more of the
technological developments forecasted, or may
depend on blending AI technology with others.
One example might be an advanced database
system integrating voice I/O, semantic checks
of data integrity, extensive deduction facilities, etc.
Annotations as mentioned above would again be
worthwhile.
The study is planned to culminate in a colloquium in March, 1978, and
in briefings to the Secretary of Defense, the President's National
Security Advisor, and Director of Central Intelligence.
Paper-length documents are due in draft form at the end of January.
(The premise is that it is more important to produce something fast
while we still have the attention of high-level people than to
produce an exhaustive study 18 months after they've stopped caring.)
In view of this accelerated time schedule, I would very much like
to have a contribution from you by the end of this month.
Producing a worthwhile document in the brief time allowed is obviously
going to take some work. On the other hand, it is interesting to
note that the study organizers have specifically requested that
artificial intelligence be included. My reading of the political
context is that the study group is being asked not to defend their
disciplines but to suggest ways of capitalizing on them. This
is a welcome change from recent experience, and ought not to be
passed by.
Comments on study organization, methodology, mail list, etc., are
most welcome.
Peter
-------
-------
∂12-Dec-77 1517 FTP:MINSKY at MIT-AI (Marvin Minsky)
Date: 12 DEC 1977 1816-EST
From: MINSKY at MIT-AI (Marvin Minsky)
To: MINSKY at MIT-AI, jmc at SU-AI
Got copy of revised letter. Ready to send it. Would you take look
at the last few entries in the big ROBOT > MINSKY;
file to see if any of those comments are worth rsponding to.
∂12-Dec-77 1516 FTP:MINSKY at MIT-AI (Marvin Minsky) Hart's technology forecast
Date: 12 DEC 1977 1815-EST
From: MINSKY at MIT-AI (Marvin Minsky)
Subject: Hart's technology forecast
To: jmc at SU-AI
I will think about it. I'm a little uncomfortable about discussing military
applications over the exposed network files. Do you think this is
a valid concern?
-- marvin
Yes, I think it's a valid concern.
∂12-Dec-77 1616 KJK dialnet
To: DIAL.DIS[P,DOC]:;
I understand there is a program at SAIL (and one at LOTS) to allow the
two computers to talk over a 300baud lline using the DIALNET protocol.
Please confirm/deny this.
NH is also interested. Tell him too.
The computers can talk, but not using the Dialnet protocol, but the
AI Lab's dial program. Mark Crispin will know details.
∂12-Dec-77 2054 FTP:MINSKY at MIT-AI (Marvin Minsky)
Date: 12 DEC 1977 2353-EST
From: MINSKY at MIT-AI (Marvin Minsky)
To: MINSKY at MIT-AI, jmc at SU-AI, reid at CMU-10A
I agree with McCarthy to send letter as is. On the publicity issue,
I have a question: many people have asked to read our correspondence
file on the subject and I think it is indeed a significant -- perhaps unique --
record of a social activity facilitated by personl network facilities.
Should I censor out the sections dealing with the Justice Letter?
It seems a shame ...but.
--Marvin
I would say no. Just put a note that the contents of the letter and
the fact that it was sent are privileged information not for publication.
∂12-Dec-77 2114 FTP:MINSKY at MIT-AI (Marvin Minsky)
Date: 13 DEC 1977 0013-EST
From: MINSKY at MIT-AI (Marvin Minsky)
To: MINSKY at MIT-AI, jmc at SU-AI, reid at CMU-10A
Yes, that sounds good. You mean, in fact, to leave the letter in, but add
that comment.
∂12-Dec-77 2119 FTP:Brian K. Reid <BR10 at CMU-10A> Re: Justice letter
Date: 13 Dec 1977 0017-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: Re: Justice letter
To: JMC at SU-AI, Minsky at MIT-AI
In-Reply-To: John McCarthy's message of 12 Dec 77 16:39
I think that it is time to send it.
Letting people read the message file is a curious point. If I say to
you that Anthony Reichelt is crazy, I have not slandered him and I am
not liable. If I say the same thing to a reporter in a public
context, I have slandered him and I am potentially liable.
I really don't know what is the legal status of letting people read
the message file. I have no personal objections to getting sued for
libel, nor do I care who sees anything that I wrote there. I stand
by all of what I've said, lawsuit or not. Whether you expunge the
Justice stuff should depend on how you intend to promulgate the
contents of the file. If you intend to take an evangelistic role and
run around showing it to people, then it would probably be best to
leave it out. If you intend to take a passive role and let people
who ask to see it come look at it, then it seems that it would be
correct to leave it in.
On the other hand, the file has been sitting on an unprotected
operating system for a month, and I would venture that there are
already 20 copies of it around the net (I have stumbled across two
here at CMU), so it probably is going to get around whether you
evangelize or not.
Brian
∂12-Dec-77 2139 FTP:MINSKY at MIT-AI (Marvin Minsky)
Date: 13 DEC 1977 0038-EST
From: MINSKY at MIT-AI (Marvin Minsky)
To: MINSKY at MIT-AI, jmc at SU-AI, reid at CMU-10A
I propose to insert this into the file:
THE FOLLOWING ITEMS ARE ENTERED HERE ANACHRONISTICALLY>
Because the "Justice Letter" below concerns our community, I
am leaving its text in this file. Because it might possibly
become part of a legal process, we think it in the public
interest that while the facts we have collected should be
disseminated to the press, the Justice Letter and the
discussion about it should not, and readers should regard it
as privileged information.
At some later time, I think the file might make an
instructive documentation of the social use of this kind of
Network, and be published -- after chcking with contributors
about their feelings. At that point, we can again decide whether to
include these details, which will then be less relevant to
the subject.
∂12-Dec-77 2144 FTP:Brian K. Reid <BR10 at CMU-10A> anachronistic insert
Date: 13 Dec 1977 0040-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: anachronistic insert
To: MINSKY at MIT-AI (Marvin Minsky)
CC: JMC at SU-AI
In-Reply-To: Marvin Minsky's message of 13 Dec 77 00:38
Looks good to me.
∂12-Dec-77 2152 FTP:MINSKY at MIT-AI (Marvin Minsky)
Date: 13 DEC 1977 0051-EST
From: MINSKY at MIT-AI (Marvin Minsky)
To: MINSKY at MIT-AI, jmc at SU-AI, reid at CMU-10A
Fascinating. Yes, I think that should be included. Morevic at SAIL
also thought the file would be of more general
interest. And Stef showed the cultural problem again;
remember Dodd's surprise to find that the bystanders just
wouldn't believe
that the Klatu was remote controlled. If engineers aren't sure, how can the
poor public be expected to make good judgments.
Science fiction readers, of course, know that the name KLATU
comes from the robot story "Farewell to the Master".
Amusing how Quasar attributes itto the phonemically impossible
explanation that it is what "You talk" sounds like backwards. When I finish this
message, I will go and try it on my tape recorder.
∂12-Dec-77 2158 FTP:Brian K. Reid <BR10 at CMU-10A> Klatu
Date: 13 Dec 1977 0056-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: Klatu
To: MINSKY at MIT-AI (Marvin Minsky)
CC: JMC at SU-AI
In-Reply-To: Marvin Minsky's message of 13 Dec 77 00:51
I'm not a Sci-fi addict myself, but I first encountered Klaatu in the
movie, "The Day the Earth Stood Still." Klaatu was a robot there, and when
they first turned it on, they told it to talk, and it repeated it backwards.
The full quote was Klaatu Barada Nikto; I don't remember what it was supposed
to mean.
Brian
∂12-Dec-77 2333 SMG
To: LES, JMC
∂12-Dec-77 2328 DCL
∂12-Dec-77 2126 SMG system overload
the pdp10 has been absolutely unusable lately. this afternoon the
load average was almost always above 10. now it is 9pm, and the load
is over 8. this is much too high.
we havent complained enough about this. the situation with the
system programmers leaving january 1 is going to make things even
more impossible, because as yet no other programmers have been hired.
the least we should ask is that jeff and marty stay until someone else has
been trained.
s
REPLY: PLEASE PASS THIS MSG. ON TO LES EARNEST AND JOHN MCCARTHY
∂13-Dec-77 0310 100 : REM
You can forget about inviting Liz and me to a party, she is no longer worth having.
∂13-Dec-77 0330 LES ERTRIS
To: HPM
CC: JMC, RAK, WLS
Once again found it with 272 pages running full tilt against a 3.4 load average.
This brings the verifiers to their knees. I am beginning to have third thoughts
about your project.
∂13-Dec-77 0818 FTP:Hart at SRI-KL (Peter Hart) Re-transmission
Date: 13 Dec 1977 0821-PST
From: Hart at SRI-KL (Peter Hart)
Subject: Re-transmission
To: JMC at SU-AI
Date: 12 Dec 1977 1511-PST
From: Hart
Subject: Help on something important
To: Duda, Nilsson, Raphael, Sacerdoti, Tenenbaum,
To: Feigenbaum at SUMEX-AIM, McCarthy at SAIL, Newell at CMU-10B,
To: Reddy at CMU-10B, Horn at MIT-AI, Minsky at MIT-AI,
To: Winston at MIT-AI, Amarel at RUTGERS-10, Uncapher at ISI,
To: Buchanan at SUMEX-AIM, Winograd at SAIL,
To: Woods at BBN-TENEXD, Anderson at RAND-UNIX
cc: Hart
As you may know, a study is being established to "forecast technology
which will drive military weapon systems for the rest of this century."
The study, which spans a broad range of disciplines, has been
specifically requested by a triumvirate consisting of Bill Perry,
Frank Press, and Stan Turner, and will therefore be visible to high
R&D policy-making levels.
I have agreed to be responsible for the section of the study
dealing with artificial intelligence. In view of the potential impact
of the forecast on longer term trends in R&D funding, it seems to me
important that it reflect the ideas of the AI community, not merely
the idiosyncrasies of one individual. Accordingly, I am asking for
your help in formulating a set of technological possibilities and,
if circumstances permit, your help in reviewing the document produced.
The ground rules of the study are that it is to focus on technological
opportunities, rather than on the likely future course of current
efforts under a "business as usual" scenario. It is important that
the relevance of these opportunities for national security be
identified as firmly as possible.
I would like specific suggestions organized under two broad classes:
Technological developments-- What improvements in AI
technology are possible over the next 20 or so
years-- for example, language understanding
sufficient to comprehend the AP wire, vision
capable of understanding any ordinary office
scene, etc. Annotations dealing with your
assessment of the degree of risk, time scale,
intuitive arguments or supporting evidence for
your candidates, etc., would be very helpful.
Systems developments-- What AI-based systems of military
significance are possible over the next 20
years. These may depend on one or more of the
technological developments forecasted, or may
depend on blending AI technology with others.
One example might be an advanced database
system integrating voice I/O, semantic checks
of data integrity, extensive deduction facilities, etc.
Annotations as mentioned above would again be
worthwhile.
The study is planned to culminate in a colloquium in March, 1978, and
in briefings to the Secretary of Defense, the President's National
Security Advisor, and Director of Central Intelligence.
Paper-length documents are due in draft form at the end of January.
(The premise is that it is more important to produce something fast
while we still have the attention of high-level people than to
produce an exhaustive study 18 months after they've stopped caring.)
In view of this accelerated time schedule, I would very much like
to have a contribution from you by the end of this month.
Producing a worthwhile document in the brief time allowed is obviously
going to take some work. On the other hand, it is interesting to
note that the study organizers have specifically requested that
artificial intelligence be included. My reading of the political
context is that the study group is being asked not to defend their
disciplines but to suggest ways of capitalizing on them. This
is a welcome change from recent experience, and ought not to be
passed by.
Comments on study organization, methodology, mail list, etc., are
most welcome.
Peter
-------
--------------------------------------------------------
John,
The SU-AI mailer hiccupped when I sent this, so just in
case you didn't receive it first time around...
-------
ok
∂13-Dec-77 0948 FTP:Buchanan at SUMEX-AIM (Response to message)
Date: 13 DEC 1977 0947-PST
From: Buchanan at SUMEX-AIM
Subject: (Response to message)
To: JMC at SU-AI
In response to your message sent 12 Dec 1977 1344-PST
I have not seen or heard from Arthur Thomas since his oral exam. Has he
done more or are you signing off on what we saw then?
Bruce
-------
He presented me with a new draft. I understood him to say that you had
seen it also.
∂13-Dec-77 1252 JJK
To: FACIL.DIS[CSD,JJK]:;
TECHNICAL GROUPS NEEDED FOR PLANNING NEW FACILITIES
Investigation of department computing needs in the last few months has
shown that much of the effort to improve our computing facilities falls
into a few key projects: computer network; terminal system; additional
computing; and utilities. The time has come to decide what to do in each
project. Volunteers with systems skills are now sought to make specific
facility plans for these important projects. If you are interested,
please contact me with your specific interests and the best times of the
week for you to meet. Also, suggest others who may be interested.
What is needed for the network project and the terminal system project are
small groups which can perform the technical and cost analyses needed to
(1) affirm project goals; (2) decide off-the-shelf adaptation vs. in-house
design; (3) come up with a choice and/or design; and (4) propose an
implementation plan and schedule, including an estimate of time, hardware,
and personnel costs. The end product of the study should be a plan which
is specific enough to be carried out by technical personnel or students
and be used for fund raising. In the case of computing and utilities,
work needs to be done on selecting major components before detailed
technical design, if any.
1. NETWORK. Likely goal is a network linking existing and future
department computers and terminal systems, serving file transfer, terminal
interaction, utility sharing, and processor interaction. Several
candidate network designs need to be evaluated. Need to judge interaction
with SCIP, etc.
2. TERMINAL SYSTEM. Likely goal is one or more high speed displays in
all offices capable of communicating to all our computers and with
features to support important programs like editors. Needs of remote
sites like DSL need to be considered.
3. COMPUTING. Likely goal is more general purpose computing for the
whole department, especially graduate students. Money is being sought for
a departmental computer. Based on various assumptions about available
funding, what configuration is best? How should the S1 and other new
machines influence future computing equipment choices?
4. UTILITIES. Goals need to be defined for a document preparation
system, sharable very large file store, and other utilities.
Thanks for your participation. You can reach me as JJK at SAIL, KING
at SUMEX, or in Polya 214, x74269.
∂13-Dec-77 1532 MRC
Your message is now a DIALnet memo (#4), FORMAT.PRO[DLN,MRC]
∂13-Dec-77 1551 FTP:Brian K. Reid <BR10 at CMU-10A> reporters
Date: 13 Dec 1977 1837-EST
From: Brian K. Reid <BR10 at CMU-10A>
Subject: reporters
To: JMC at SAIL
I assume that the reporter from Outside magazine has already
contacted you. I don't think I've ever tried to talk with
a dumber human being. Who knows! the National Enquirer may be next.
She did, but she must have been too tired to display dumbness. Anyway,
I have about decided to refuse to talk with further reporters on the
grounds that I have done my bit for journalism for this year.
∂13-Dec-77 1842 HPM So sorry
To: LES, JMC, RAK, WLS
∂13-Dec-77 0330 LES ERTRIS
To: HPM
CC: JMC, RAK, WLS
Once again found it with 272 pages running full tilt against a 3.4 load average.
This brings the verifiers to their knees. I am beginning to have third thoughts
about your project.
[(Blush) Well, it checks load average and number of jobs only every frame,
which sometimes gives it a time resolution of over 5 minutes (especially
if the load is high and its not getting run a lot).
Also it currently goes to sleep if the load average is over 2.5. So that
when it's 3+ε, it notices and goes to sleep for a few minutes. But that
soon drops the load average by 1, making it 2+ε, and it resumes running
for another frame, bringing the load up to 3+ε again, stopping it
afterwards ... .
I'll include a running/not-running mod in the load average check to
overcome this, and lower the bounds. Also I'll try to move the test into a
more deeply nested position, so it will be checked more often.
Apologetically yours,
Low profile Moravec
∂14-Dec-77 0138 FTP:Su-Ai at SRI-KA (Stanford Ai lab) REM
Date: 14 Dec 1977 0139-PST
From: Su-Ai at SRI-KA (Stanford Ai lab)
Subject: REM
To: RWG at SAIL, JMC at SAIL
Do FINGER REM at SAIL and :NAME REM at MC. It seems to clearly say that he's
gonna kill himself in a month. I realize it is a crock of shit and he's done
this before to attract attention, but still a suicide threat is something to
be paid attention to in any case. In my opinion, REM should be committed!
Not to protect other people, but to protect himself. From what I've seen he's
his own worst enemy.
-- MRC
-------
∂14-Dec-77 0921 FTP:Buchanan at SUMEX-AIM (Response to message)
Date: 14 DEC 1977 0920-PST
From: Buchanan at SUMEX-AIM
Subject: (Response to message)
To: JMC at SU-AI
In response to your message sent 13 Dec 1977 1157-PST
If you could send down your copy of Thomas's thesis I'd be able
to look at it in the next several days. He did not send me one or talk to me
about it, though.
Ed says you will be CSD chairman next quarter -- congratulations and
good luck.
Bruce
-------
∂14-Dec-77 1422 REF Comments on Reiger's CSA and the Marvellous Drinkng Bird:
1) The whole thing would have (perhaps) been easier to understand
if Reiger had sent you all of the paper. As it is, you have two
copies of some pages, and no copies of some (even numbered) others.
2) Reiger seems to have a "network" language for expressing
various types of "causation". He also has a simulator
for simulating these networks. His notation is sufficiently
obscure (and perhaps the mechanisms are sufficiently difficult)
that it is hard to what exactly is happening. The missing pages
don't help, nor does the tendency to use this paper as a reference
manuel for his system.
3) It seems that what statements he makes with his different
kinds of arrows can also be expressed as WFF's. He also provides
a simulator, but this can be viewed as an elementary, directed theorem
prover (it's proving simple theorems about specific states).
4) There is some question as to whether his primatives are
"adequate" to discribe all mechanisms. I sort of doubt it, but am
not sure which ones can't be used. Perhaps some mechanism dependent
upon the partial differential equations of heat transfer can louse
up his simulator, perhaps mechanisms dependent upon simultanity of
events, perhaps impossible mechanisms can be created in which various
states block the preconditions for each other. Probably all of these
can be done, as:
5) I said, (3), it's just a system for declaring some axioms, and
then theorem proving. And nothing keeps you from declaring contradictory
or otherwise ridiculous axioms.
6) And there's little within this system (as near as I can tell,
in my quick and irregular reading) that keeps you from declaring any mechanism,
perpetual motion machine, or incorrect explanation of the drinking bird.
For example, in his explanation, I don't see where the composition of the
red fluid is mentioned, except as "change vol W-I-G {RATE}" (does that
imply he thinks it's "water-in-glass"?
Oh well. The paper's back in your mailbox. Thanks.
Could you write to Rieger and ask for better documentation? If his description
of how it works is consistent with the hypothesis that the fluid is water,
then his description is probably wrong, because almost certainly water
won't work.
∂14-Dec-77 2019 RCM Sato material and my SRI login
I don't have your copy of Sato's thesis or the McCarthy,Sato, et al paper.
I returned them to Patte the day after I borrowed them last summer. However,
I made a copy of the latter which I could bring in for you to copy if you
can't find yours.
My login at SRI is BMOORE (J Moore gets very annoyed if you send my mail to
MOORE). I login there about every other day, but I am here at SAIL at least
that often in the evening and on weekends. For maximum probability of reaching
me try both.
Yes, please bring in the McC-Sato paper and give it to Patte to copy.
∂15-Dec-77 2024 RCM McCarthy-Sato paper
I made a copy of the McCarthy-Sato paper and put it in your mail box.
That was easier than lending it and then getting it back.
∂17-Dec-77 2309 REM via AMET DIALNET, TELENET, ET AL TO BE ILLEGAL MAYBE
To: MRC, JMC
I don't know how likely it is to pass, others in PCNet say it
can't possibly pass, but then Nixon got elected... but the phone company
has a task force that has proposed a bill to congress that will forbid
any connection between dial-telephone and specialized common carriers such
as computer networks. See front page of Computerworld (the issue in Comp
Sci Library this Thursday, I forgot to check which date it was) for article.
I haven't yet checked AP/NYT for additional info, do either of
you know anything about it?
∂17-Dec-77 2359 MRC Ma Bell s***s long and totally
To: JMC, REM
Yah, I have heard rumors of that kind. Of course, neither DIALnet nor
PCnet are really "networks" but rather point-to-point communication
protocols. If Ma tried to make them outlawed they would have to flush
ordinary terminal-computer communications as well.
Why? Take the example of a smart terminal taking, say, SUPDUP protocol to
a foreign site. What is the SIGNIFICANT difference between that and
Dialnet? Or, look the other way...what is the difference between that
and a dumb terminal like an ADM-3. There is no clear difference where the
cretins can draw the line.
It will, of course, be amusing to see exactly what Ma does. She would be
screwing herself, since the Bell Labs guys have their own sort-of Dialnet
running now for file transfer. I am not worried though. If TELENET uses
ordinary phone communications, they have something to worry about!
[Mark]
∂18-Dec-77 0023 MRC Christmas party (maybe)
To: PEOPLE.DIS[1,MRC]:;
To: Everybody I could think of off the top of my head who might come
As you all might have noticed in the system message, I'm thinking of arranging
some kind of a party for Christmas evening; wine and cheese variety, but if
people want something different, that's alright. I'd like to do this since
this is my first Christmas that I'm not spending with my parents and I thought
it would be sort of a nifty idea. Also, I owe a couple of people on this
list a party, SO...
I have really no idea of where or what but I'm open to ideas. The main idea
is just to have sort of a fun type social gathering with friends, or lovers,
or family or whatever.
I'd like to know who is interested and maybe what ideas they have. Maybe
this could be the start of a tradition or something. In any case, I intend
to do SOMETHING this Christmas!
Hope to hear from enough of you....
∂19-Dec-77 1017 CR Phone Message
Gordon Bell, Digital Equipment Corporation, will call you back after Christmas. He
left a new number for your records: (617)493-2236.
∂19-Dec-77 1205 RWW
∂15-Dec-77 1823 JMC
I do have your copy of Gentzen. Back soon, most likely tonight.
THANKS
∂19-Dec-77 1224 FTP:SUZUKI at PARC-MAXC The decision procedure for quantified S expressions
Date: 19 DEC 1977 1224-PST
From: SUZUKI at PARC-MAXC
Subject: The decision procedure for quantified S expressions
To: JMC at SAIL
Date: 19 DEC 1977 1223-PST
From: SUZUKI
Subject: THE Decsion Procedure for Quantified S expressions.
To: OPPEN at SAIL, MCCARTHY at SAIL, JEFFERSON at CMUA
cc: SUZUKI
I have not thought about this algorithm for so long that I have
forgotten most of, but the talk with Derek helped me to reconstruct.
Please send me
messages if you find them satisfactory.
1) Transform the formula (existentially closed) to
Prenex normal form
2) Simplify the car cons, and cdr cons sequences, by the rule
Car(cons(x,y)) -> x
cdr(cons(x,y)) -> y.
3) Remove cons in favor of car and cdr.
cons(a,b)=c -> a=car(c) & b=cdr(c).
cons(a,b)#c -> c=nil or a#car(c) or b#Cdr(c).
4) Change the innermost quantifier to E.
(Ax) -> not(Ex) not
5) Change the matrix to disjunctive normal form
6) Distribute E over each disjunct
7) From here on we consider the formula of the form
(Ex)(A1 & A2 & ... & An)
where each Ai is an atomic formula.
Case 1. If x is not free in A1 &...&An we are done and just remove
(EX), then goto step 4).
Case 2. If x free, then transform it to
(Ex)(B1 & ... & Bj) & Bj+1 & ... & Bn
where x only appear in B1, B2, ... , Bj.
Then goto 8)
8) If there are equalities among B1, ..., Bj then we do the
following.
Let C1, ..., Ci be the all the equalities among B1,...,Bj.
If any of the equality has x on both sides the formula is either T or F. If the formula is e=e,
where e can be x or c{a,d}+r(x), then it is just
replaced by T. If it is e=f where e and f are syntactically
distinct the entire disjunct (Ex)(A1 & ... &An)
is false and replace it by F. Now we have the formuas of the form
g(x)=e
where g(x) is x or c{a,d}+r(x). We define the signature of
g(x) to be omega when g(x) is x, and {a,d}+
when g(x)
is c{a,d}+r(x). We define a partial order on the signature
as follows.
(As).(s <= omega),
(As).(Car(s)<s & cdr(s)<s).
Now, among C1,...,Ci , we find a formula of the x with the largest
signature. This may not be unique. (In case we have
x=e, we have a unique largest signature.)
Let the formula with the largest signature be of the form
g(x)=e.
Then substitute all the occurence of g(x) be e and replace
g(x)=e by T. Then go to 7).
9) If there are no more equalities we do the following.
If there is a negation of equlaity with x appearing on both sides, then it is replaced
by either T or F. If the signature is identical then it is replaced
by F. Otherwise T.
If the negation of the equlaity is of the form
g(x)#y
where y is an identifier, then just replace
it by T. If it is of the form
g(x)#car(e) or g(x)#cdr(e)
then replace it by
e#nil.
Repeat steps 4) to 9) until all the quantifiers are
removed. Then the formula consists only of T and F,
so we can determine the validity.
As I have written in the title this only works for S-expressions
without circularities. Justification should be easy from some
axiom sets, which I believe cannot be first order because of
saying something like there is no cicularities. If I have
some time and interests I will try to do them. Nori
-------
-------
∂19-Dec-77 1305 DCO s-expressions
To: suzuki at PARC-MAXC, JMC, DCO, jefferson at CMU-10A
I still do not believe your decision procedure. Take, for instance,
step 8 where you are considering equalities between terms containing your
existentially--quantified variable x. You say "If the formula is e = e
then replace by T; if it is of the form e = f where e and f are syntactically
distinct the entire disjunct Ex(A1 & ... & An) is false". This is surely
wrong. If I have a formula Ex(car(x) = cdr(x)), your decision procedure will
return FALSE!!!
∂19-Dec-77 1333 JJK
Professor McCarthy -- A very brief description of your work is needed for the
revised Computer Forum brochure. Is this paragraph satisfactory to you?
John McCarthy, 1971 Turing Lecturer and member of the American Academy of
Arts and Sciences, is Professor of Computer Science and Director of the
Artificial Intelligence Laboratory. He is well known for the development
of the programming language LISP and as an early proponent of timesharing.
Most of his recent research efforts have been devoted to representation
theory and the mathematical theory of computation. Some recent advances
suggest the possibility of new treatments of the problem of proving program
correctness in more complex programs than possible until now, and of unifying
the methods of proving correctness in both parallel and sequential programs.
No, not satisfactory.
∂19-Dec-77 1358 FTP:SUZUKI at PARC-MAXC Re: s-expressions
Date: 19 DEC 1977 1359-PST
From: SUZUKI at PARC-MAXC
Subject: Re: s-expressions
To: DCO at SU-AI
cc: SUZUKI, jmc at SAIL, jefferson at CMUA
In response to your message sent 19 Dec 1977 1305-PST
I see your point, but to fix it is not a big deal.
Eauality)
If we have an equality g(x)=f(x)
where we g(x), and f(x) are expressions of the form
c{a,d}*rx. If the signatures are comparable, we can say T or F
depending on whether they are
identical or not.
If they are not comparable, treat it as a part of substitution equality. Namely substitue g(x) for f(x) if f(x) is the signature of the largest order and replace it by T.
Negation of equality)
If we have an inequality of the form g(x)#f(x),
if the signatures are comparable then we replace it by T or F depending
on whether g(x) and f(x) are distinct or not. If
they are not comparable, then just replace by T at step 9),
remember we do not have any more equalities around anymore.
Thanks for the comments and finding out the bugs!
Do you now believe it?
Or do you rather want to see the proof? Maybe I will
find some more bugs while I am proving.
-------
∂19-Dec-77 1438 DCO
To: suzuki at PARC-MAXC, JMC, DCO, jefferson at CMU-10A
I guess I will have to wait for the proof! What do you mean by
"comparable"?
I will send you a copy of my linear algorithm for satisfiability
of conjunctions. You will notice that it constructs a "graph" representing
the constraints put on all the variables by equalities and inequalities.
This graph is the reasonably obvious one - the vertex representing car(x)
is the left successor of the vertex representing x, etc.
To use it as the base step in a quantifier-elimination method,
assume first the formula is of the form ExF(x,y) where y is any variable
quantified farther out in the prefix. Using the equalities and disequalities
involving x, construct the graph. If the graph has any cycles or contains
equalities explicitly denied by a disequality, return 'UNSATISFIABLE.
Otherwise, "unparse" the graph back into a formula involving only y.
That is, for every pair of vertices representing subterms in the formula
(but not subterms involving x) which are constrained in some way (i.e.
either to be equal or to be disequal or to be an atom or not to be an atom -
the latter two constraints for a single vertex, of course), add to the
formula being constructed this constraint. (e.g. if one node represented
y1, another y2, and the constraint that the two nodes had to be disequal were
asserted, then we will include y1 ≠ y2 in the formula we are constructing).
This unparsing step is okay since we have already made sure that if unsatisfiability
is due to constraints just on x, then we have detected them; if they are due to
x and y, we have still saved the information necessary by unparsing the graph to
give us this information. (This depends on the lemma proved in the paper that
the graph is "bidirectionally closed", which means that all entailed equalities
are explicitly represented in the graph.)
It is the unparsing step which is the critical one and where your algorithm
seems to be too vague. I presume your steps 8 and 9 are trying to do what I
describe above, but it is not obvious these steps are subtle enough. I am
sure that your algorithm catches things like x ≠ car(x) - i.e. "vertical"
constraints in the graph - but I am not sure it catches all the horizontal
constraints.
Anyway, it is an interesting problem, isn't it? I will see you
after christmas.
∂19-Dec-77 1447 DCO
To: suzuki at PARC-MAXC, JMC
Whoops, forgot to add -
But there are easier ways to prove decidability of a class of theories
including the theory of s-expressions: shown in the paper. I also note there
that the theory cannot be decided efficiently.
∂19-Dec-77 1508 FTP:SUZUKI at PARC-MAXC (Response to message)
Date: 19 DEC 1977 1509-PST
From: SUZUKI at PARC-MAXC
Subject: (Response to message)
To: DCO at SU-AI
cc: SUZUKI, jmc at SAIL
In response to your message sent 19 Dec 1977 1438-PST
It is hard read your staff on the screen so I will be waiting for your
manuscript. I am writing up the proof with axiomatization. The axiomatization is
quite similar to the aziomatization of the elementary number theory.
What I meant by comparable signatures is that
car and cdar are comparable since there is a path in the partial order tree
but car and cdr are not comparable since there is not a path. I wonder whether
this kind of research will do any impact on computer science per se, but
it certainly is an exercise. Nori
-------
∂19-Dec-77 1514 FTP:SUZUKI at PARC-MAXC (Response to message)
Date: 19 DEC 1977 1515-PST
From: SUZUKI at PARC-MAXC
Subject: (Response to message)
To: DCO at SU-AI
cc: SUZUKI, jmc at SAIL
In response to your message sent 19 Dec 1977 1447-PST
It has been known n that if the first order theory iwth equality has no finite
models and aleph-0 categorical it is decidable. The theory of S-expression falls
into this calss , so that the decidability is fairly trivial once we believe in the
axiomatization. All we are doing is , I guess, whether classical way of showing
decidability can be agian applied. Nori
-------
∂19-Dec-77 1529 FTP:SUZUKI at PARC-MAXC NP-completenss of the theory
Date: 19 DEC 1977 1529-PST
From: SUZUKI at PARC-MAXC
Subject: NP-completenss of the theory
To: oppen at SAIL, jmc at SAIL
cc: suzuki
I thought about the complexity of the algorithm. the NP-completenss seems trivial
since one can encode propositional calculus in this theory, using formulas
like x=y for any propostional letters. Nori
-------
∂20-Dec-77 0934 CR Phone Message
Gardner Lindsey called 12/20 and left no message.
∂20-Dec-77 1743 REM
[Note by REM: Gee, good thing somebody put it here. I've always
thought a visionary was a person who fortold the future, and have
thus misunderstood HOTER.ESS[ESS,JMC] ever since I read it in
1973. Too bad HOTER.ESS doesn't have a glossary to explain such
obscure and misleading jargon.]
∂21-Dec-77 0017 FTP:Boyer at SRI-KL (Bob Boyer) The Correctness of a Decision Procedure for Prop. Calculus
Date: 21 Dec 1977 0017-PST
From: Boyer at SRI-KL (Bob Boyer)
Subject: The Correctness of a Decision Procedure for Prop. Calculus
To: TPG:
J Moore and I have gotten our theorem prover to do a proof of the
correctness of a propositional calculus decision procedure. The
algorithm works on IF trees (3 place COND'S). It first puts
the formula in an "IF Normal Form" by rewriting
all (IF (IF A B C) D E)'s to (IF A (IF B D E) (IF C D E))'s.
Then the decision procedure checks that on every branch through
the normalized if tree the tests force the output to be true (or else
the tests simply prevent the branch from actually being taken).
The soundness of the algorithm is proven with respect to an evaluator
for if trees called VALUE which takes a term to evaluate and
and an alist of bindings. VALUE fetches the bindings on
each test and switches accordingly.
The completeness of the algorithm is proven with the help of the
function FALSIFY which computes an alist which causes VALUE to
return F provided that the decision procedure (which actually checks
for tautologies and is called TAUTOLOGY.CHECKER) returns F.
A list of the proofs and definitions (including proofs of termination)
can be had at [SRI-KL]<THOR>TAUT.PROOFS. The only notational
quirk is that (CONS x y z w) means (CONS x (CONS y (CONS z w))).
Bob & J
-------
∂21-Dec-77 1005 FTP:MINSKY at MIT-AI (Marvin Minsky)
Date: 21 DEC 1977 1305-EST
From: MINSKY at MIT-AI (Marvin Minsky)
To: jmc at SU-AI
Do you remember who was collecting history of SPACEWAR?
Apparently there is a recent patent on TV games that seems
excessively restrictive, and I wondered who to refer an interested party to.
marvin
Lawyers for Atari were collecting it, in connection with a patent infringement
suit by Magnavox, which Magnavox won. More recently, a lawyer for Fairchild
was collecting similar material. He seemed to think that Atari hadn't defended
itself very well, and Fairchild would do better. The last activity I heard of
was about a year ago. I might be able to dig up the name of the Fairchild
lawyer if you want me to.
∂21-Dec-77 1301 FTP:Boyer at SRI-KL (Bob Boyer) A subtle termination argument.
Date: 21 Dec 1977 1300-PST
From: Boyer at SRI-KL (Bob Boyer)
Subject: A subtle termination argument.
To: ZM at SU-AI, JMC at SU-AI, WALDINGER
In the proof of our tautology checker, we mentioned that we used
a function for "normalizing" if's. The function is defined this
way:
normalize(x) <=
if x has the form IF(IF(A,B,C),D,E) then
normalize(IF(A, IF(B,D,E), IF(C,D,E)))
elseif X has the form IF(A, B, C) then
IF(A, normalize(B), normalize(C))
else x.
Would you please lend your experienced ear to our proof that the
function normalize is total; the proof is a rather queer one, and
we thought perhaps you might see a simpler argument.
The question of course is what's going down. We (and the theorem
prover) find that the pair <if.complexity(x), if.depth(x)> decreases
on every recursive call in the lexicographic order on pairs of
integers (<m,n> < <m', n'> if and only if m<m' or (m=m' and n<n')).
if.depth(x) is defined as:
if x has the form IF(A, B, C) then 1+if.depth(A)
else 1.
if.complexity(x) is defined as:
if x has the form IF(A, B, C) then if.complexity(A)*(if.complexity(B)+
if.complexity(C))
else 1
The proof that the if.depth is reduced when the "noramlization" call
occurs is easy enough.
We then have to prove that the if.complexity stays even during the
normalization call and goes down during the other two
recursions.
The proof that the if.complexity stays even is just a bunch of arithmetic.
Letting A,B,C,D, and E also stand for their if.complexities, we
have if.complexity(IF(IF(A,B,C),D,E)) =
ABD + ABE + ACD + ACE =
if.complexity (IF(A, IF(B,D,E), IF(C,D,E))).
The proof that the if.complexity goes down during the two other recursions
is the fact that AB+AC is greater than B and greater than C, provided that
all of A, B, and C are greater than 0, which the definition
of if.complexity provides.
The ugliest thing about this proof is its use of arithmetic.
Sometimes, use of arithmetic is just a disguise for the more elegant
ordinal considerations. But we couldn't find the ordinal argument that
could replace all that arithmetic.
Hoping you see a prettier proof,
Bob & J
-------
∂22-Dec-77 1035 DPB AI colloquium
Bob Filman has been asked whether there will be credit available for the
AI colloquium being started this winter. We can probably do it easily
enough. Do you approve of the idea? Do you think the series will be
worth 1 credit to passive attendees? If necessary, you may be called upon
to be the "official" instructor in charge, which would only mean that you
fill out the grade sheet with + for each enrollee. What's your vote?
-Denny
Sure, why not? Apropos of yours of 22 Dec.
∂25-Dec-77 1336 JP maclsp pty's
john, I implemented a preliminary version of the facility you mentioned to
me a while ago. Let me know if you are interested in using it. -J
∂26-Dec-77 0541 REM Data-compressing
I have a new version of HOTER.FAI (PTYOLD) that performs data-compression
on output, thus allowing greater than 30 cps thruput when using 300 baud
dialup lines (I am using it right now as I type this message), and I have
a 6502 program in my 6502 that performs decompression locally, (which I
am also using now). Normal output is faster than normal, and rows
full of common characters are much faster. Of course, rows of rare
characters like "Q" are much slower than normal.
∂28-Dec-77 1307 REF
Stark is scheduled for Monday, January 23, 4:00. Thanks for the lead.
∂28-Dec-77 2117 DCO
To: suzuki at PARC-MAXC, JMC
∂19-Dec-77 1528 FTP:SUZUKI at PARC-MAXC NP-completenss of the theory
Date: 19 DEC 1977 1529-PST
From: SUZUKI at PARC-MAXC
Subject: NP-completenss of the theory
To: oppen at SAIL, jmc at SAIL
cc: suzuki
I thought about the complexity of the algorithm. the NP-completenss seems trivial
since one can encode propositional calculus in this theory, using formulas
like x=y for any propostional letters. Nori
-------
[ NO! As you point out, it is a trivial observation that the theory is NP-hard,
i.e. that it is at least hard to decide as the propositional calculus, since it
contains the propositional calculus. To show it is NP-complete, you have to
show that the theory is in NP, that is, that it is no harder to decide than the
propositional calculus. NP-hardness is NOT NP-completeness!]
∂29-Dec-77 1120 HVA NSF Proposal - Basic Research in Artificial Intelligence
CC: JMC, LES, RWW
Sponsored Projects Office has called Dr. Barrett, NSF this a.m. The Proposal
is still in the review process and it will be at least 6-8 weeks before any
decision is reached. As we surmised, funding will not begin, therefore, on
1 Jan.'78, as the review process still seems to require 6 months; Stanford
sent off proposal 9/21/77. (By the way. Spons. Proj. Office rec'd the post
card with Correspondence No. 78-0052).
Thanks, Hershe.
∂29-Dec-77 1537 LES KA10 mortgage agreement
To: JC
CC: JMC, HVA
JMC and I agree to your spending funds in the Townsend account up to
the limit of what is there, using the KA10 as collateral.
The interest rate will be .00001% per year, compounded every picosecond.
∂29-Dec-77 1733 FTP:Wiederhold at SUMEX-AIM System curriculum approval
Date: 29 DEC 1977 1724-PST
From: Wiederhold at SUMEX-AIM
Subject: System curriculum approval
To: floyd at SAIL, barth at SAIL, sso at SAIL, jmc at SAIL,
To: dpb at SAIL, feigenbaum
cc: jlh at SAIL, wiederhold
1 29 Dec JLH at SU-AI (John He Systems curriculum
2 29 DEC To: JLH at SU-AI Re: Systems curriculum
1 -- ************************
Mail from SU-AI rcvd at 29-DEC-77 1704-PST
Date: 29 Dec 1977 1703-PST
From: JLH at SU-AI (John Hennessy)
Subject: Systems curriculum
To: wiederhold at SUMEX-AIM
Gio,
Whats the story with the systems curriculum.
Has Floyd looked at it. It seems to me and Jeff
that we should push it through at the CS faculty meeting.
John
-------
2 -- ************************
Date: 29 DEC 1977 1719-PST
From: Wiederhold
Subject: Re: Systems curriculum
To: JLH at SU-AI
cc: WIEDERHOLD
In response to your message sent 29 Dec 1977 1703-PST
I , and Susan Owiccki have sent messages to Floyd and all others who could possibly
be concerned with no avail or response. We have proposed a meeting of the
curriculum coomittee prior to the faculty meeting , that would be at 2pm.
I had also suggested that the systems faculty be included. My suggestion now
is that we do it anyhow, and decide who is a quorum. I had asked DEnny for
a list of the members of the curriculum committee, but havent heard from
him either, so that by copy of this I am asking him to mail this message to
anyone concerned. I f we wait much longer it wont get into the bulletin etc etc.
Gio
-------
-------
∂30-Dec-77 1014 FTP:Wiederhold at SUMEX-AIM Curriculum committee meeting
Date: 30 DEC 1977 1015-PST
From: Wiederhold at SUMEX-AIM
Subject: Curriculum committee meeting
To: green at SAIL, luckam at SAIL, appelt at SAIL
cc: wiederhold, jmc at SAIL, floyd at SAIL
1 29 Dec JLH at SU-AI (John He Curr. Comm.
2 29 DEC To: dpb at SAIL, fei System curriculum approval
1 -- ************************
Mail from SU-AI rcvd at 29-DEC-77 1744-PST
Date: 29 Dec 1977 1743-PST
From: JLH at SU-AI (John Hennessy)
Subject: Curr. Comm.
To: wiederhold at SUMEX-AIM
Gio,
Curr. comm. is supposedly Floyd, Green, YOU, Luckam, McCarthy
(as LOTS director), and Appelt.
John
-------
2 -- ************************
Date: 29 DEC 1977 1724-PST
From: Wiederhold
Subject: System curriculum approval
To: floyd at SAIL, barth at SAIL, sso at SAIL, jmc at SAIL,
To: dpb at SAIL, feigenbaum
cc: jlh at SAIL, wiederhold
1 29 Dec JLH at SU-AI (John He Systems curriculum
2 29 DEC To: JLH at SU-AI Re: Systems curriculum
1 -- ************************
Mail from SU-AI rcvd at 29-DEC-77 1704-PST
Date: 29 Dec 1977 1703-PST
From: JLH at SU-AI (John Hennessy)
Subject: Systems curriculum
To: wiederhold at SUMEX-AIM
Gio,
Whats the story with the systems curriculum.
Has Floyd looked at it. It seems to me and Jeff
that we should push it through at the CS faculty meeting.
John
-------
2 -- ************************
Date: 29 DEC 1977 1719-PST
From: Wiederhold
Subject: Re: Systems curriculum
To: JLH at SU-AI
cc: WIEDERHOLD
In response to your message sent 29 Dec 1977 1703-PST
I , and Susan Owiccki have sent messages to Floyd and all others who could possibly
be concerned with no avail or response. We have proposed a meeting of the
curriculum coomittee prior to the faculty meeting , that would be at 2pm.
I had also suggested that the systems faculty be included. My suggestion now
is that we do it anyhow, and decide who is a quorum. I had asked DEnny for
a list of the members of the curriculum committee, but havent heard from
him either, so that by copy of this I am asking him to mail this message to
anyone concerned. I f we wait much longer it wont get into the bulletin etc etc.
Gio
-------
-------
-------
∂30-Dec-77 1201 JJK
∂27-Dec-77 1913 JMC
No, not satisfactory.
Would you care to suggest changes or replacements in the text? The
one I sent you combines text from the version of the Forum booklet
that is being replaced plus information from the most recent AI Lab
reseach report.
∂31-Dec-77 1027 FTP:Wiederhold at SUMEX-AIM FYI: meting of curriculum committee
Date: 31 DEC 1977 1026-PST
From: Wiederhold at SUMEX-AIM
Subject: FYI: meting of curriculum committee
To: bs at SAIL, dpb at SAIL, rwf at SAIL, jlh at SAIL,
To: jmc at SAIL, feigenbaum
cc: wiederhold, sso at SAIL
Date: 31 DEC 1977 1022-PST
From: Wiederhold
Subject: Re: curriculum committee
To: DCL at SU-AI
cc: WIEDERHOLD, gren at SAIL, appelt at SAIL, green at SAIL
In response to your message sent 30 Dec 1977 1422-PST
The curriculum committee will meet to discuss the system
curriculum which was proposed last year ( copies with
Carolyn Tajnai in CS ) and present it for approval , if possible at
the faculty meeting following. ( same place )
<<< sorry you weren't informed earlier , I only received
a note giving the composition of the committee yesterday >>> Gio
-------
-------
∂31-Dec-77 1856 FTP:CARL at MIT-AI (Carl Hewitt) My evaluators
Date: 31 DEC 1977 2156-EST
From: CARL at MIT-AI (Carl Hewitt)
Subject: My evaluators
To: jmc at SU-AI
CC: CARL at MIT-AI
My evaluator contains no side effects. It will however interpret
LISP expressions of the form (lambda (x1 ... xk) e1 ... en)
which you may not like and so I have removed this "feature" even though
it is used in all the LISP implementations that I know about.
I apologize for the typo in evaluate←clauses.
Enclosed are two evaluators written in MACLISP that will correctly interpret
definitions written in pure MACLISP subject to the above restriction.
For example (lambda (n) (print n) (print (add1 n))) will not work.
I have tested them on fibonacci, reverse, and create←pair (which is like cons).
The reason that you got the error message that car was not defined is because
of an idiosyncrasy in the treatment of the evaluation of the functional position in
MACLISP. The interpreters given below cater to this idiosyncrasy.
I hope that you find these evaluators more useful than the previous ones.
Sincerely,
Carl
P.S. I am sorry that I did not get back to you sooner with these interpreters
but was tied up with adminstration at the end of the term at M.I.T.
P.P.S. Could you please send me a current copy of the evaluator.
(defun bind←identifiers (identifiers values environment expression)
(cond ((null identifiers)
(cond ((null values)
environment)
(t (error '|Too Few Arguments| expression))))
((null values)
(error '|Too Many Arguments| expression))
(t (cons (list (car identifiers) (car values))
(bind←identifiers (cdr identifiers)
(cdr values)
environment
expression)))))
(defun lookup (identifier environment)
(cond ((null environment)
(error '|Unbound Variable| identifier))
((equal identifier (caar environment))
(cadar environment))
(t (lookup identifier (cdr environment)))))
(defun bound? (identifier environment)
(cond ((null environment)
nil)
((equal identifier (caar environment))
(cadar environment))
(t (bound? identifier (cdr environment)))))
!
; First define the evaluator which uses dynamic scoping:
(defun dynamic←eval (expression environment)
(cond ((atom expression)
(cond ((or (null expression) (equal expression 't) (numberp expression))
expression)
(t (lookup expression environment))))
((atom (car expression))
(cond ((eq (car expression) 'quote)
(cadr expression))
((eq (car expression) 'lambda)
expression)
((eq (car expression) 'cond)
(dynamic←eval←cond←clauses (cdr expression) environment))
(t (dynamic←apply (car expression)
(dynamic←eval←list (cdr expression) environment)
expression
environment))))
(t (dynamic←apply (dynamic←eval (car expression) environment)
(dynamic←eval←list (cdr expression) environment)
expression
environment))))
(defun dynamic←apply (procedure arguments expression environment)
(cond ((atom procedure)
(cond ((get procedure 'expr)
(dynamic←apply (get procedure 'expr) arguments expression environment))
(t
(apply procedure arguments))))
((eq (car procedure) 'lambda)
(dynamic←eval (caddr procedure)
(bind←identifiers
(cadr procedure)
arguments
environment
expression)))
(t (error '|Unknown Procedure| (list procedure arguments)))))
(defun dynamic←eval←cond←clauses (clauses environment)
(cond ((null clauses)
nil)
((dynamic←eval (caar clauses) environment)
(dynamic←eval (cadar clauses) environment))
(t (dynamic←eval←cond←clauses (cdr clauses) environment))))
(defun dynamic←eval←list (expressions environment)
(cond ((null expressions)
nil)
(t (cons (dynamic←eval (car expressions) environment)
(dynamic←eval←list (cdr expressions) environment)))))
!
; Now by changing the way that lambda expressions are evaluated
;we obtain an interpreter which uses lexical scoping [like the lambda calculus of Church
;and ALGOL-60]:
(defun lexical←eval (expression environment)
(cond ((atom expression)
(cond ((or (null expression) (equal expression 't) (numberp expression))
expression)
(t (lookup expression environment))))
((atom (car expression))
(cond ((eq (car expression) 'quote)
(cadr expression))
((eq (car expression) 'lambda)
(list 'closure (cdr expression) environment))
((eq (car expression) 'cond)
(lexical←eval←cond←clauses (cdr expression) environment))
((bound? (car expression) environment)
(lexical←apply (lookup (car expression) environment)
(lexical←eval←list (cdr expression) environment)
expression))
(t (lexical←apply (car expression)
(lexical←eval←list (cdr expression) environment)
expression))))
(t (lexical←apply (lexical←eval (car expression) environment)
(lexical←eval←list (cdr expression) environment)
expression))))
(defun lexical←apply (procedure arguments expression)
(cond ((atom procedure)
(cond ((get procedure 'expr)
(lexical←apply (lexical←eval (get procedure 'expr) ())
arguments
expression))
(t
(apply procedure arguments))))
((eq (car procedure) 'closure)
(lexical←eval (cadadr procedure)
(bind←identifiers (caadr procedure)
arguments
(caddr procedure)
expression)))
(t (error '|Unknown Procedure| (list procedure arguments)))))
(defun lexical←eval←cond←clauses (clauses environment)
(cond ((null clauses)
nil)
((lexical←eval (caar clauses) environment)
(lexical←eval (cadar clauses) environment))
(t (lexical←eval←cond←clauses (cdr clauses) environment))))
(defun lexical←eval←list (expressions environment)
(cond ((null expressions)
nil)
(t (cons (lexical←eval (car expressions) environment)
(lexical←eval←list (cdr expressions) environment)))))
(defun fib (n)
(cond ((zerop n) 1)
((equal n 1) 2)
(t (plus (fib (difference n 1)) (fib (difference n 2))))))
(defun reverse (l)
(cond ((null l)
nil)
(t
(append (reverse (cdr l)) (list (car l))))))
(defun create←pair (x y)
(lambda (m)
(cond ((equal m 'left)
x)
((equal m 'right)
y)
(t (error '|Unknown Message| m)))))
(defun left (l) (l 'left))
(defun right (l) (l 'right))
(lexical←eval '((create←pair 3 4) 'left) ()) ;this wins
(lexical←eval '(left (create←pair 3 4)) ()) ;this wins
(dynamic←eval '((create←pair 3 4) 'left) ()) ;this loses
(dynamic←eval '(left (create←pair 3 4)) ()) ;this loses
∂01-Jan-78 0400 MRC
∂01-Jan-78 0019 JMC
Have you "improved" TN so that <ctrl><meta>q doesn't work?
MRC - No. αβQ works. Please explain how it does "not work".
∂01-Jan-78 2239 FTP:CARL at MIT-AI (Carl Hewitt)
Date: 2 JAN 1978 0140-EST
From: CARL at MIT-AI (Carl Hewitt)
To: jmc at SU-AI
CC: CARL at MIT-AI
In my "p.p.s" in previous message I meant to ask for a current copy of the
paper not the evaluator. The final version of the paper has to be in by March 1.
I hope that you have sent copies to your colleagues on the LISP project and
gotten their comments back.
Sincerely,
Carl
∂02-Jan-78 1624 MRC
Read 4THAGE.PDL[1,MRC] -- I found it on PDL@DM's directory just
now. It is GOOD!
∂02-Jan-78 1629 SGK Passport
I think my passport is in one of the files in perhaps the top drawer
of your safe. Would you please check? Thanx
∂02-Jan-78 2324 DPB
∂02-Jan-78 1146 JMC faculty meeting agenda
What items do you know of for that agaenda?
The important one, of course, is degree recommendation.
The Curriculum committee will probably have a report, to comment on the new
systems curriculum.
Bob Floyd may want to discuss the teaching, seminar reqs.
I will have something to say about visitors.
Gene Golub may have Admissions news.
Announcement of Gray Tuesday meeting.
Announcement of composition of Appts and Promotions Comm.
Computer Forum announcements?
I have not talked to most of the people who may want to report. I hope
to have a very short, crisp meeting. -Denny
∂03-Jan-78 0909 TED
About the broken <ctrl> key - are both broken or only one and which one?
∂03-Jan-78 1235 FTP:EF at MIT-AI (Edward Fredkin)
Date: 3 JAN 1978 1057-EST
From: EF at MIT-AI (Edward Fredkin)
To: JMC at SU-AI
Hi, you might be interested
in a memo I wrote, called "The Comprehensive System". It is in
my directory EF at AI, and is in the form CS(ready for tj6 to make an
XGP output, that is CS >, and also CS XGP, or there is CSM > and
CSM MEMO (or is it CS MEMO?) ) Anyway, have a look in my directory
and get a copy. I'd really appreciate your comments.
Best regards, Ed Fredkin
~
∂04-Jan-78 0949 TED GUESS WHAT.
CC: JMC
WELCOME BACK. JMC'S IMLAC JUST BROKE IN A CURIOUS WAY. IT SEEMS TO COMPLEMENT
THE 100 BIT OF THE CHARACTER WHEN <CONTROL> IS DEPRESSED INSTEAD OF HAVING ANY
PROPER EFFECT. WHEN THE LOADER (START AT 40) IS RUN, AN ALPHABET TYPED (AND
WATCHED WITH PK) OMITS THE CHARACTERS B,C,D,I,K,L,R,S AND T. TYPING NUMBERS
0-9 GAVE p,q,r,s,u,v,w,x,y. SOUNDS TO ME LIKE A PROBLEM IN THE TRANSMITTER
CARD IN THE IMLAC AS THE PROGRAM IN GENERAL SEEMS TO RUN. OH, I JUST THOUGHT,
IT MIGHT ALSO BE IN THE TTY SCANNER RECEIVER. ANYWAY LET'S LOOK AT IT PLEASE.
∂04-Jan-78 1058 FTP:Hart at SRI-KL (Peter Hart) AI Technology Forecast
Date: 4 Jan 1978 1059-PST
From: Hart at SRI-KL (Peter Hart)
Subject: AI Technology Forecast
To: Feigenbaum at SUMEX-AIM, JMC at SU-AI, Minsky at MIT-AI,
To: Amarel at RUTGERS-10, Uncapher at USC-ISI,
To: Winograd at SU-AI, Rick at RAND-UNIX, Denicoff at USC-ISI,
To: Russell at USC-ISI
Following is a quite detailed suggested outline for a paper & presentation
on opportunities for AI to impact the DoD in the next 25 years. In addition
to any general comments you might have, I am particularly interested in
feedback on the following points:
1. Is the discussion framework described in Section II worthwhile?
2. What parts of the paper would appear naive or silly to DoD
people with operational concerns.
3. The suggested applications in Sections III and IV are purely
straw men. Comments on prioritizing these suggestions, and
additional suggestions, are especially welcome.
4. The section on Soviet possibilities is virtually empty. Information
from those having insight into Soviet programs is badly needed.
5. The Conclusions are currently weak.
For comments to be of any real help, I will need to receive them by mid-January.
Thanks for the help.
Peter
===============================================================================
ARTIFICIAL INTELLIGENCE AND NATIONAL SECURITY --
Some Opportunities
Peter E. Hart
OUTLINE
I INTRODUCTION
A. Definition of AI
1. example AI systems
a) natural language access to databases
b) medical diagnosis
c) picture processing
d) HASP-ish signal processing
e) chess (for war-gaming analogies)
f) continuous-speech understanding
g) robotics
2. symbolic vs. numerical computation
B. Purpose of paper
1. emergence of AI from the laboratory
2. continuation of "business as usual"--
some predictable effects
3. goal of identifying opportunities
a) opportunities vs. predictions
b) awareness of possibilities vs. attempt
to prioritize application goals
c) attempt to do more than immediate
extrapolation of current state of AI
4. disclaimers
a) standard hazards of futurology
b) AI people generally lack deep understanding
of operational defense problems
C. Some assumptions
1. AI appetite for cycles and memory will accelerate
2. hardware evolution-- Noyce article
D. Organization of paper
preview of sections
II THE INFORMATION PROCESSING CYCLE AND APPLICATIONS
TO NATIONAL SECURITY
A. Information flow in a system and its environment:
analyze --> plan --> act --> monitor --> analyze
1. interpretation/analysis of input
a) non-AI examples
i) formal languages, standard parsing
ii) data format checks
b) AI examples
i) natural language input
ii) picture analysis
c) contrast non-AI vs. AI
range of acceptable variation
2. planning a course of action
a) non-AI examples
i) numerical calculations
ii) conventional database access
b) AI examples
i) robot planning
ii) unconventional database access
c) contrast non-AI vs. AI
range of acceptable variation
d) AI systems can operate flexibly only
through use of large "knowledge bases,"
"models," etc.
3. acting
a) means for a system to affect environment
b) lack of AI vs. non-AI distinction
c) examples
i) report generation (standard output)
ii) control of aerodynamic surfaces
iii) control of sensors
4. monitoring effects of actions
a) people routinely monitor effects
b) conventional control systems monitor effects
c) conventional informations processing systems
do not monitor effects
d) most AI systems do not monitor effects
B. National security application areas
1. Weapons systems applications
2. Command, control, and communication applications
3. Intelligence applications
4. Support systems applications
C. Application areas vs. system functions:
characterize interaction between application
areas and system functions as a table:
\ Function |
\ |
\ |
\ | Interpret/ Plan Act Monitor
\ | analyze
Appl'n. \ |
area \ |
----------------\-----------------------------------------------------
|
Weapons | ... ... ... ...
|
C↑3 | ... ... ... ...
|
Intelligence | ... ... ... ...
|
Support | ... ... ... ...
|
----------------------------------------------------------------------
D. The table as a discussion guide
1. Opportunities exist for integrated systems that
perform all of the functions in a row
a) examples
i) autonomous cruise missile
ii) integrated command and control system
2. Opportunities exist for systems occupying only
a single cell
a) examples
i) natural language front ends
ii) picture analysis for reconnaissance
III EXAMPLES OF INTEGRATED SYSTEMS
A. Autonomous control of space-borne laser weapons
1. Plausible need for system-- space as a battlefield
2. Interpretation of input:
multi-sensor, multi-platform input; evaluation
of intent of other platforms; alert
supervisory ground control
3. Planning:
create plan to achieve ground-specified goal;
coordinate multiple friendly platforms
4. Acting:
power management; weapons management
5. Monitoring:
assess effects of actions; modify actions;
notify ground
6. Technical requirements:
requires advances on many fronts; 25 years?
B. Autonomous control of multiple cruise missiles
1. Desirabilty-- operate with organization and
flexibility
2. Interpretation of input:
multi-modal input; assess enemy intentions
3. Planning:
as in (A) above; notion of sacrifice
4. Acting:
control surfaces; thrust; weapons
5. Monitoring:
effects of own actions; enemy actions; losses
6. Technical requirements:
probably similar to (A)
C. Commander's management aid
1. Need-- present coherent status report to help
evaluate feasibility of missions; help organize
mission once decided upon
2. Interpretation of input:
voice or typed natural language I/O
3. Planning:
identify resources needed; schedule
processes
4. Acting:
issue plans subject to commander's approval
5. Monitoring:
receive status reports; identify significant
variations from plan; re-plan/re-schedule
6. Technical requirements:
natural front-end interface to commander/staff;
automatic planning, constraint satisfaction;
plan monitoring
D. Multi-platform EW reconnaissance
1. Need-- maintain an updated EOB
2. Interpretation of input:
analysis of multi-modal EW sensor systems
3. Planning:
sensor management; mission specification
4. Acting:
real-time control of sensors
5. Monitoring:
evaluation of adequacy of current data
for EOB maintenance
6. Technical requirements:
analysis of sensory data; mission planning
E. Automated manufacturing
1. Need-- cost of defense systems; quick response to
demands for new or modified hardware; ability
to stockpile production facility components
2. Interpretation of input:
specification of workpieces by factory-floor
personnel or by CAD-produced specs; analysis
of input from video, tactile and other sensors
3. Planning:
automated specification of detailed manufac-
turing steps; specification of inspection
tests for quality control
4. Acting:
real-time control of effectors and sensors
5. Monitoring:
effects of motor actions; workpiece inspection
and rework
6. Technical requirements:
simplfied user I/O (not necessarily full
natural language); analysis of sensory data;
automatic planning and monitoring; could be
achieved by evolution-- no breakthroughs
appear to be needed
F. Automated maintenance instructor and operational aid
1. Need-- High turnover, low skill level of maintenance
personnel; high proportion of DoD personnel
in maintenance function
2. Interpretation of input:
Voice I/0; analysis of video and special
purpose sensors
3. Planning:
automatic specification of diagnostic and
repair procedures; automatic synthesis of
instructional messages
4. Acting:
voice/video output to user
5. Monitoring:
check physical progress; determine if procedure
employed by user is adequate if not optimal
6. Technical requirements:
analysis of video and other sensory data;
voice analysis; automatic planning/monitoring
IV EXAMPLE OF APPLICATION MODULES
A. Weapons systems
1. Terminal guidance using video and other sensors
2. Real-time ECM penetration aid
B. Command, control, and communications applications
1. Integrity of database updates using semantic checks
2. User-adaptive front-end for message systems or
databases
C. Intelligence applications
1. Reconnaissance imagery monitoring/exception reporting
2. Plan deployment of reconnaissance sensors in
real time
3. Intelligence analysts aid; economic/political
modelling
D. Support systems applications
1. Manpower scheduling/deployment using constrained
search
2. Contract and program management; status monitoring
V UNDERLYING AI TECHNOLOGY
A. Research themes in AI
1. natural language, speech
2. image understanding
3. deduction
4. planning
5. execution monitoring
6. expert systems
7. AI languages/systems
8. program verification
B. Breakthrough opportunities/needs:
two candidate problems where breakthroughs, rather
than evolutionary advances, are needed
1. smart exploitation of multi-processor architectures:
memory access problems; problem partitioning
2. acquisition and management of large knowledge bases:
acquiring knowledge of non-AI specialists;
knowledge management in vision, planning,
common-sense deduction, constraint satisfaction
VI SOVIET DEVELOPMENTS
A. Difficulty of obtaining good technical information
B. General backwardness of Soviet computing
C. General high level of Soviet interest in AI
1. IJCAI attendance
2. close monitoring of Western work
D. High spots
1. chess
2. robots
E. Prognosis
1. continue to lag Western work
2. ability to concentrate resources on a few
problems
VII CONCLUSIONS
[currently weak-- needs suggestions]
A. Limitations on technology over next 25 years
1. combinatorics-- e.g., plan "optimal" movement
of all materiel in the DoD inventory on a global
basis
2. problems requiring enormous conceptual bases--
e.g., automatic specification of priorities for
major equipment purchases
3. ethics and values-- e.g., determination of when
to escalate a conflict
B. Prioritizing national needs and research opportunities
1. need to identify critical technology base issues
2. balance between applications developments and
longer term research
3. desirability of this balance in single institutions:
close coupling of research and applications
4. shortage of trained personnel-- the pipeline problem
C. Other......?
-------
∂04-Jan-78 1500 FTP:Feigenbaum at SUMEX-AIM Re: Forest Baskett
Date: 4 JAN 1978 1501-PST
From: Feigenbaum at SUMEX-AIM
Subject: Re: Forest Baskett
To: SSO at SU-AI
cc: jmc at SAIL, dpb at SAIL
In response to your message sent 4 Jan 1978 1443-PST
Susan, Forest will be on leave for a third year next year. Gio will
continue as his replacement.
I am copying John McCarthy and Denny Brown since they are running the show while
I am on a one-quarter sabbatical leave.
ed
-------
∂04-Jan-78 1500 FTP:Feigenbaum at SUMEX-AIM Re: Forest Baskett
Date: 4 JAN 1978 1501-PST
From: Feigenbaum at SUMEX-AIM
Subject: Re: Forest Baskett
To: SSO at SU-AI
cc: jmc at SAIL, dpb at SAIL
In response to your message sent 4 Jan 1978 1443-PST
Susan, Forest will be on leave for a third year next year. Gio will
continue as his replacement.
I am copying John McCarthy and Denny Brown since they are running the show while
I am on a one-quarter sabbatical leave.
ed
-------
∂04-Jan-78 1534 FTP:Feigenbaum at SUMEX-AIM recommendation for appointment
Date: 4 JAN 1978 1535-PST
From: Feigenbaum at SUMEX-AIM
Subject: recommendation for appointment
To: jmc at SAIL
cc: dpb at SAIL, sso at SAIL
Mail from SU-AI rcvd at 4-JAN-78 1325-PST
Date: 4 Jan 1978 1321-PST
From: SSO at SU-AI (Susan Owicki)
Subject: A & P business
To: Feigenbaum at SUMEX-AIM
CC: EJM
I suggest John Guttag as a potential candidate for the vacant slot
(junior faculty level). You might want to talk to Ed McCluskey, who
has had some initial evaluations on him.
If you want, I can send you another copy of his vita.
-Sue
-------
-----------------------------------------------------------------------
Denny,
would you forward this on to Floyd as committee chairman?
--------------------------------------------------------------------------
-------
∂04-Jan-78 1624 MLG
@MSG.[1,GG]
∂04-Jan-78 1652 EJM via AMET teasching language
To: JMC
CC: EAF
since floyd is the author of one of the candidate languages
i think that the decision on which one to use should be
the responsability of some other committee. Specifically
no one involved with one of the languages should be on the
committee which will reccommend a language to the department.
A neutral party such as golub would be a better choice to
head the committee that acts on this issue.
∂04-Jan-78 1701 GG thanks
We are leaving now to go back to Italy. We are sorry we coldn't find you to
personally thank you for the excellent time we had here. Anyway it was really
a great pleasure for us to stay here. Bye bye.
Maria and Pina Gini
∂05-Jan-78 0902 FTP:Taynai at SUMEX-AIM (Response to message)
Date: 5 JAN 1978 0903-PST
From: Taynai at SUMEX-AIM
Subject: (Response to message)
To: DPB at SU-AI
cc: JMC at SAIL
In response to your message sent 4 Jan 1978 1806-PST
I will make sure the following course is validated through the
Registrar's office:
CS320 1 unit Artificial Inelligence Seminar McCarthy DCPower Lab
Conf. Room
Please let me know time when it is determind.
Thanks,
Carolyn
-------
∂05-Jan-78 1954 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR TUESDAY 10TH JANUARY
PLACE: ERL 237
TIME: 2.30 pm.
ORGANIZATIONAL MEETING
***********************
This is intended to be a short meeting to set up an agenda for our
subsequent seminars. In particular people should suggest recent
papers and topics that they would like to present and outside
speakers they would like to invite.
Also, any change in time for the seminar will be voted on.
Since there is a clash with the Polya/Tarjan course CS150, some people
may want to change the usual time.
∂06-Jan-78 0812 BS Faculty Meeting Minutes
I have the draft of the minutes of the faculty meeting ready for you.
Shall I send a copy to the Lab or do you plan to be in Polya?
I assume that the faculty salary you need is high, median and low
by RANK? I will have this for you later today.
Betty Scott
∂06-Jan-78 1715 JBR
You have exceeded your disk quota.
The files listed below have been purged to reduce your disk
area to your quota of 2000
Before purging, your files occupied 2839
You have too many files. The purger may not select the
optimum set.
PPSAV.TMP[F77,JMC]
SIGART.LST[LET,JMC]
ENERGY.LST[LET,JMC]
LEADER.LST[LET,JMC]
NEWELL.LST[LET,JMC]
GTREE.LST[206,JMC]
DIALNE.LST[DIA,JMC]
CRYPT.DMP[ 2,JMC]
CODE.DMP[ 2,JMC]
SOURC2.LAP[ 1,JMC]
WEIZEN.XGP[W76,JMC]
HOTER.XGP[W76,JMC]
FINAL.XGP[S77,JMC]
MENTAL.XGP[F76,JMC]
CERT.XGP[F77,JMC]
REPRES.PRO[ 1,JMC]
FUNS[ 1,JMC]
EPIS[ 1,JMC]
P1[ 1,JMC]
PART[ 1,JMC]
PERM[ 1,JMC]
PATH2[ 1,JMC]
PATH[ 1,JMC]
ANTIN[ 1,JMC]
SYLL[ 1,JMC]
MEET[ 1,JMC]
COMPIL[ 1,JMC]
TIMES[ 1,JMC]
TESTA.SAI[ 1,JMC]
TESTC.SAI[ 1,JMC]
TESTB.SAI[ 1,JMC]
TESTD.SAI[ 1,JMC]
DADDA[ 1,JMC]
ORDIN[ 1,JMC]
PROB1[ 1,JMC]
ROTAT.SAI[ 1,JMC]
ROTA.SAI[ 1,JMC]
ROTB.SAI[ 1,JMC]
ROTC.SAI[ 1,JMC]
SEMAA[ 1,JMC]
SEMAB[ 1,JMC]
INTER[ 1,JMC]
CONVER.SAI[ 1,JMC]
RELREP[ 1,JMC]
MC[245,JMC]
PATH[245,JMC]
PATH2[245,JMC]
DEMO[ 1,JMC]
LISPAD[ 1,JMC]
TESTE.SAI[ 1,JMC]
ICOM[ 1,JMC]
TRANS1[ 1,JMC]
SIMUL[ 1,JMC]
COMPU2[ 1,JMC]
SOURC2[ 1,JMC]
SOURCE[ 1,JMC]
PUZZ.SAI[ 1,JMC]
TCLUBA[ 1,JMC]
TCLUB[ 1,JMC]
BOARDS.SAI[ 1,JMC]
NEWDOC[ 1,JMC]
REFER.ENC[225,JMC]
MCCRAC.LET[ 1,JMC]
PATHS.RLS[225,JMC]
PARKER[ 1,JMC]
GRPALG.RLS[225,JMC]
GRPDAT.RLS[225,JMC]
GROPER.RLS[225,JMC]
DIMEN.RLS[225,JMC]
CHAR.RLS[225,JMC]
LARRY2[ 1,JMC]
COMPU2.LET[ 1,JMC]
DEG5.IN[225,JMC]
S4.REP[225,JMC]
REPRES.RLS[225,JMC]
DEG6.IN[225,JMC]
R42.IN[225,JMC]
ANNOUN[225,JMC]
PUZZ.SAI[225,JMC]
PUZZA.SAI[225,JMC]
PANIC.SOS[225,JMC]
PUZZB.SAI[225,JMC]
ENCYC1.PRO[ESS,JMC]
PUZZE.SAI[225,JMC]
DRIVE.DIR[ AI,JMC]
MINE.DIR[ AI,JMC]
PTCH2.DIR[ AI,JMC]
KNOW2.AI[ESS,JMC]
ARTNA1.ART[ESS,JMC]
RECOG.LET[ 1,JMC]
MEMMTC.QUA[ESS,JMC]
LANG1.AI[ESS,JMC]
MTC71.QUA[ESS,JMC]
S5.QUA[ESS,JMC]
R1301.ART[ESS,JMC]
R1303.ART[ESS,JMC]
N30[ 1,JMC]
QA.PRO[ESS,JMC]
ARTNAT.ART[ESS,JMC]
SEMAN.AI[ESS,JMC]
FRANK.STA[ESS,JMC]
COMPUT.STA[ESS,JMC]
MTCSYL.QUA[ESS,JMC]
AISY69.QUA[ESS,JMC]
FILEC.FAI[ESS,JMC]
LETTVI.REV[ESS,JMC]
R1300.ART[ESS,JMC]
LCFMEM.MTC[ESS,JMC]
PEARL.NOT[ESS,JMC]
PUZZ.RLS[226,JMC]
PUZB.SAI[226,JMC]
PUZZ.SAI[226,JMC]
TRANS.DOC[226,JMC]
BLISET.PRF[226,JMC]
BLISET.COM[226,JMC]
IMPROV.DOC[226,JMC]
SETRUL.DOC[226,JMC]
PCHECK.M2[226,JMC]
COND.PRF[226,JMC]
BACKSL[ 1,JMC]
SYSTEM.HAC[226,JMC]
SORTS.DOC[226,JMC]
ADD.PRF[226,JMC]
TH1.PRF[226,JMC]
TH1.COM[226,JMC]
PCHECK.M1[226,JMC]
ADD.COM[226,JMC]
NETJO2.PRO[ESS,JMC]
FALSE.PRF[226,JMC]
DI[226,JMC]
SCWORL.AX2[226,JMC]
ONE.PRF[226,JMC]
IPT73.REP[ESS,JMC]
NSFX.2[ESS,JMC]
NSFX.6[ESS,JMC]
NSFX.5[ESS,JMC]
NSFX.7[ESS,JMC]
NSFX.9[ESS,JMC]
NSFX.8[ESS,JMC]
NSFX.3[ESS,JMC]
NSFX.4[ESS,JMC]
HAYES.FRM[ESS,JMC]
ADTEL2.NOT[ESS,JMC]
PLATT.NOT[ESS,JMC]
REPRES.BIB[226,JMC]
ONTO.NOT[226,JMC]
TASK1.MAR[ESS,JMC]
TASK2.MAR[ESS,JMC]
LETTER.HE2[ESS,JMC]
XLET[ESS,JMC]
ZF.AX[ESS,JMC]
FOO73A[ESS,JMC]
FOON.PR1[ESS,JMC]
ROTE.SAI[ 1,JMC]
ROTD.SAI[ 1,JMC]
ROTF.SAI[ 1,JMC]
SWOPSI.RE[ESS,JMC]
HART.ME1[ESS,JMC]
GGGG[ESS,JMC]
PRO[ESS,JMC]
M29AUG.MES[ESS,JMC]
SYMPOS[ESS,JMC]
CH1.BH2[ESS,JMC]
CLOCK.FAI[ESS,JMC]
FONTS[ESS,JMC]
SLIDES[ESS,JMC]
FACMIN.MEM[ 1,JMC]
W74.PLN[226,JMC]
CLASS.REG[226,JMC]
GAME.CHK[226,JMC]
FOO1[ESS,JMC]
FOL2.MEM[226,JMC]
FOL1.MEM[226,JMC]
WUTHER.QUE[ESS,JMC]
ROY[LET,JMC]
TOLLES.LET[LET,JMC]
FORDH.LET[LET,JMC]
AD.NET[ESS,JMC]
KNUTH.SAI[225,JMC]
NEWRUL.DOC[226,JMC]
COMPUT[ 1,JMC]
TOLLES.LE1[LET,JMC]
TUCKER.LET[LET,JMC]
TUCKER.LE2[LET,JMC]
TCLUB.MEM[ESS,JMC]
GEN1[ AI,JMC]
DRIVE3[ AI,JMC]
MPRO[ AI,JMC]
PUTCH[ AI,JMC]
PUTCH.DIR[ AI,JMC]
DRIVE[ AI,JMC]
AIBIB[ AI,JMC]
MINE[ AI,JMC]
NOTES2[ AI,JMC]
PUTCH3[ AI,JMC]
RUSS[ AI,JMC]
CHYLIN.LE1[ AI,JMC]
SLAMEC.LE2[LET,JMC]
BOWDEN.LE1[LET,JMC]
CHERN.LE2[LET,JMC]
MAY.ME[LET,JMC]
NSFX.10[ESS,JMC]
MC.AI[ESS,JMC]
HENRY[ESS,JMC]
BIRKHO.LE1[LET,JMC]
FLANAG.LE1[LET,JMC]
ERIK.LE6[LET,JMC]
BARAB[ 1,JMC]
TAMBOV[ 1,JMC]
HARPER.LE1[LET,JMC]
PUZZE.F4[225,JMC]
ERIK.LE7[LET,JMC]
BAJCSY.LE1[LET,JMC]
STARKM.LE1[LET,JMC]
MT[ 1,JMC]
BRIT.LET[LET,JMC]
IRANI.LE1[LET,JMC]
BOWEN.LE1[LET,JMC]
JAF.STA[ESS,JMC]
RECUR[ESS,JMC]
ANDERS.RE1[ 1,JMC]
PEOPLE[226,JMC]
MCQUIL.LE1[LET,JMC]
PAM.LE1[LET,JMC]
DRLUK.LE1[LET,JMC]
OCT.ME[LET,JMC]
OLSEN.LE1[LET,JMC]
ERIK.LE0[LET,JMC]
SUBCOM.LE1[LET,JMC]
MICHIE.LE2[LET,JMC]
NEWSCI.LE1[LET,JMC]
AHLHAU.LE1[LET,JMC]
MEMOS.CUR[LET,JMC]
PUBINT.LE1[LET,JMC]
HORNIN.LE1[LET,JMC]
FELDST.LE1[LET,JMC]
CHECK.DEP[LET,JMC]
TUCKER.LE1[LET,JMC]
SCANDU.LE1[LET,JMC]
MELTZ.LE1[LET,JMC]
PIASET.LE1[LET,JMC]
MILNER.REC[LET,JMC]
FLESS.LE1[LET,JMC]
TRESSL.LE1[LET,JMC]
PIASET.LE2[LET,JMC]
LICKL.LE1[LET,JMC]
COOP.LE1[LET,JMC]
POE.LE1[LET,JMC]
JMILLE.LE2[LET,JMC]
IGARAS.LE1[LET,JMC]
ITO.LE1[LET,JMC]
CLARK.LE1[LET,JMC]
FLESS.LE2[LET,JMC]
MICHIE.LE3[LET,JMC]
TAVARE.LE1[LET,JMC]
SCIENC.LE1[LET,JMC]
SCRIB.LE1[LET,JMC]
ATKIN.LE1[LET,JMC]
KOCHEN.LE1[LET,JMC]
GREER.FAC[LET,JMC]
CU.LE1[LET,JMC]
RALSTO.LE2[LET,JMC]
MESSAG.SCI[LET,JMC]
MCCRAC.LE2[LET,JMC]
RALSTO.LE3[LET,JMC]
CHRON.LE1[LET,JMC]
LOGIC.QUA[LET,JMC]
SHIGER.LE1[LET,JMC]
PAMELA.LE1[LET,JMC]
TAUGNE.LE1[LET,JMC]
MORGAN.LE2[LET,JMC]
FROOK.LE1[LET,JMC]
LOMONA.LE1[LET,JMC]
APR.ME[LET,JMC]
LOGIC.PUB[LET,JMC]
CONSUL.LE1[LET,JMC]
VERE.LE1[LET,JMC]
PAWLAK.LE1[LET,JMC]
TSUDA.LE1[LET,JMC]
NOLL.LE1[LET,JMC]
ROBERT.LE1[LET,JMC]
RILI.LE1[LET,JMC]
RALSTO.LE1[LET,JMC]
MORGAN.LE1[LET,JMC]
MIYA.LE1[LET,JMC]
HEALTH.LE1[LET,JMC]
WILKS.LE1[LET,JMC]
LAST.LE1[LET,JMC]
SEDEL.LE1[LET,JMC]
CAMPB.LE1[LET,JMC]
ARDEN.LE1[LET,JMC]
BURNS.LE1[LET,JMC]
SHOCK.LE1[LET,JMC]
CU.LE2[LET,JMC]
DAVID.LE1[LET,JMC]
SCHOEL.LE1[LET,JMC]
CALHOU.LE1[LET,JMC]
FINCH.LE1[LET,JMC]
LYKOS.LE1[LET,JMC]
JMILLE.LE1[LET,JMC]
MITCH.LE1[LET,JMC]
JERRY.LE1[LET,JMC]
FORSHA.LE1[LET,JMC]
COMPT.LE1[LET,JMC]
STORK.LE1[LET,JMC]
ASTRO2.ART[ESS,JMC]
R1302.ART[ESS,JMC]
FRIEDM.LE1[LET,JMC]
FF[ESS,JMC]
AIRLIN.MTC[ESS,JMC]
JFOL.USE[ESS,JMC]
MEARS.LET[LET,JMC]
GRIMM.BKP[ESS,JMC]
SCIAM.LE1[LET,JMC]
NYT.LE1[LET,JMC]
NAVROZ.LE1[LET,JMC]
LISPN[ 1,JMC]
TECH[ 1,JMC]
NOTES1[ AI,JMC]
TXP1.LSP[ 1,JMC]
STARK.LE1[LET,JMC]
REPRES[LET,JMC]
MDAVIS.LE1[LET,JMC]
IGARAS.LE2[LET,JMC]
GLUGG[LIT,JMC]
GLUGG2[LIT,JMC]
KNOW.NOT[ AI,JMC]
FLESS.LE0[LET,JMC]
KNOW.ART[ AI,JMC]
YOUNG.LE1[LET,JMC]
KILPAT.LE1[LET,JMC]
JAF.STA[LET,JMC]
PERSON[ 1,JMC]
MEIR.LE1[LET,JMC]
JAF.LE2[LET,JMC]
NAS.NOT[ESS,JMC]
MCCRAC.LE1[LET,JMC]
PIERCE[ 1,JMC]
TELLER.LE1[LET,JMC]
LARRY[ 1,JMC]
CRYPT.FAI[ 2,JMC]
WEISSK.LE1[LET,JMC]
MICHIE.LE1[LET,JMC]
AAAS.PRO[ESS,JMC]
3D.NSF[ESS,JMC]
ONEILL.NOT[ESS,JMC]
ISRAEL.LE1[LET,JMC]
ISRAEL.ART[LET,JMC]
CORBAT.LE1[LET,JMC]
CHENEY.LE1[LET,JMC]
OCTOBE.OUT[LET,JMC]
COMNEE[ 1,JMC]
CALHOU.LE2[LET,JMC]
EFOO[ESS,JMC]
COMTOP.LIS[ESS,JMC]
MICHIE.LE4[LET,JMC]
INFO.NEE[ESS,JMC]
AIMEM2.JMC[226,JMC]
NET1[ 1,JMC]
EVANS.LE1[LET,JMC]
EVANS.LE2[LET,JMC]
ALUMNI[ 1,JMC]
NETDOC.PLN[ESS,JMC]
INFO[ 1,JMC]
LIB.PRO[ 1,JMC]
SUFFIC.FRE[LET,JMC]
OCT.USE[ESS,JMC]
OLIVER.LE1[LET,JMC]
INTRO.AI[ 2,JMC]
COMMON.NS[LET,JMC]
ADMIS.LET[LET,JMC]
DRELL.LE1[LET,JMC]
SIGART.LE2[LET,JMC]
SIGART.LE1[LET,JMC]
SIGART.BUL[LET,JMC]
BOWEN.LE2[LET,JMC]
RUSSOF.NOT[ESS,JMC]
INVOIC[LET,JMC]
ACM.LE2[LET,JMC]
ACM.LE1[LET,JMC]
JOSHI.LE1[LET,JMC]
FERRIS.LE1[LET,JMC]
NYT.LE2[LET,JMC]
SOCIAL[ 1,JMC]
BDAY.LIT[LIT,JMC]
AILAB.AIL[ESS,JMC]
EXTFOR.MEM[258,JMC]
ACTOR0[258,JMC]
NONTER.PRB[258,JMC]
CORREC.ABS[258,JMC]
BACKUP.MCP[258,JMC]
HOMOMO.NOT[258,JMC]
MCP.PR1[258,JMC]
COND.PRF[258,JMC]
PQR.PRF[258,JMC]
SCHEM.WRU[258,JMC]
GREEK.JMC[258,JMC]
MCCUS.PRO[258,JMC]
BRACEW.LE1[LET,JMC]
FOLSCO.MEM[258,JMC]
NAUR.LE1[LET,JMC]
FEMANO.LE1[LET,JMC]
MTC.GRP[ESS,JMC]
PETERS.LE1[LET,JMC]
JAN.ME[LET,JMC]
LEGUIN.CRI[LIT,JMC]
JAN14.DBX[258,JMC]
SUM.CAR[ 1,JMC]
GELLMA.LE1[LET,JMC]
ESSEX.LE1[LET,JMC]
HOBBS.LE1[LET,JMC]
BREMER.LE1[LET,JMC]
SHELDO.NS[LET,JMC]
APPEND.CON[258,JMC]
LOOKUP.SPE[ 1,JMC]
FOLMAN.MOD[258,JMC]
CONSUL.POX[ESS,JMC]
AILET[LET,JMC]
REYNOL.LE1[LET,JMC]
ACM.LE3[LET,JMC]
LEAST.CM1[258,JMC]
NORBYE.LE1[LET,JMC]
JAN.OUT[LET,JMC]
DEC74.IN[LET,JMC]
OUTLIN.256[258,JMC]
HAND.2[258,JMC]
JO.NOT[258,JMC]
MTC.BLA[258,JMC]
LOGIC.QUA[258,JMC]
HAND.W75[258,JMC]
MANNA.PR2[258,JMC]
MANNA.CM2[258,JMC]
OKAMOT.LE1[LET,JMC]
HARDPR.OOF[258,JMC]
MANNA.WRU[258,JMC]
DEMO.PR1[258,JMC]
HAND3.W75[258,JMC]
CHRI.LE1[ 2,JMC]
VIS[ 2,JMC]
VIS1[ 2,JMC]
VIS.CAP[ 2,JMC]
NNN[ 2,JMC]
VITASK[ 2,JMC]
FRAGA.LE1[LET,JMC]
GORDON.LE1[LET,JMC]
FIELDS.ME2[LET,JMC]
ENERGY.LE1[LET,JMC]
GORDON.LE2[LET,JMC]
FEB.ME[LET,JMC]
DEC.ME[LET,JMC]
TASK[LIT,JMC]
ADHOC.THE[258,JMC]
SAKAI.LE1[LET,JMC]
LICK[ESS,JMC]
LICK.LE1[LET,JMC]
LICK.ME1[LET,JMC]
PARTIT.LSP[ 1,JMC]
HAND.1[258,JMC]
BIBLE[245,JMC]
USER[245,JMC]
IDEAS[225,JMC]
SUZUKI.REC[LET,JMC]
SAKAI.LE2[LET,JMC]
MUFTIC.LE1[LET,JMC]
VOR1[ 1,JMC]
IGR.AX[226,JMC]
SCINT.AX[226,JMC]
ORD1.AX[226,JMC]
MCP.AX[258,JMC]
MCP2.AX[258,JMC]
MCP3.AX[258,JMC]
LIST.AX[226,JMC]
REST.AX[226,JMC]
TERMS.AX[226,JMC]
SET.AX[226,JMC]
INT.AX[226,JMC]
INTEG2.AX[258,JMC]
COND.AX[258,JMC]
SCWORL.AX[226,JMC]
W0.AX[226,JMC]
EQUA.AX[226,JMC]
ORD2.AX[226,JMC]
SEQ.AX[226,JMC]
INDUC.AX[258,JMC]
INTEGE.AX[258,JMC]
COMPIL.AX[258,JMC]
LISP.AX[226,JMC]
ADMIND.AX[226,JMC]
SCOTT.AX[226,JMC]
SET3.AX[226,JMC]
SET2.AX[226,JMC]
ZF.AX[258,JMC]
EQUAL.AX[258,JMC]
EXTFOR.AX[258,JMC]
BLISET.AX[226,JMC]
COND.AX[226,JMC]
MRHUG.QUE[226,JMC]
ASHLEY.LE1[LET,JMC]
74DEC1.AJT[LET,JMC]
SMITH.LE1[LET,JMC]
GAREY.LE1[LET,JMC]
BERG.LE2[LET,JMC]
KOREA.POL[S75,JMC]
KOREA.2[S75,JMC]
ENGINE.LE1[LET,JMC]
RUSSIA.LE1[LET,JMC]
GELFAN.LE1[LET,JMC]
MT.PRO[ 1,JMC]
AUG75.OUT[MSG,JMC]
SEP75.OUT[MSG,JMC]
JAN75.OUT[MSG,JMC]
DEC74.OUT[MSG,JMC]
MAR75.OUT[MSG,JMC]
APR75.OUT[MSG,JMC]
MAY75.OUT[MSG,JMC]
JUN75.OUT[MSG,JMC]
JUL75.OUT[MSG,JMC]
MAR75.IN[MSG,JMC]
INGERM.LE1[LET,JMC]
APR75.IN[MSG,JMC]
FR2[ 1,JMC]
SQUIBS.PRO[ 1,JMC]
FRA[ 1,JMC]
MODEST[S75,JMC]
IDEOLO.ESS[CUR,JMC]
CHESS1[CUR,JMC]
SOCIAL.DEF[CUR,JMC]
RAMSEY[CUR,JMC]
HOW.ESS[CUR,JMC]
LEADER.ART[CUR,JMC]
LICK.PRE[CUR,JMC]
REPRES.LIC[CUR,JMC]
REPRES.LI2[CUR,JMC]
GOALS.LIC[CUR,JMC]
TWOMOD.ESS[CUR,JMC]
FORMAL.PRO[CUR,JMC]
SALARY.MEM[CUR,JMC]
SCIP[CUR,JMC]
IDEOLO[CUR,JMC]
ECON.NOT[CUR,JMC]
AICIRC.ABS[CUR,JMC]
CPDUST[CUR,JMC]
IDEOLO.ART[CUR,JMC]
APHOR.AI[CUR,JMC]
ECO.ESS[CUR,JMC]
RACKET.ESS[CUR,JMC]
PROPOS.BLA[CUR,JMC]
PHIL[CUR,JMC]
COMMON[CUR,JMC]
MENTAL[CUR,JMC]
NEWS75.MOD[CUR,JMC]
EXEC.SUM[CUR,JMC]
PRODUC.ESS[CUR,JMC]
STANDA.ESS[CUR,JMC]
ARPMTC[CUR,JMC]
1974.IN[MSG,JMC]
JAN75.IN[MSG,JMC]
ARPA75.OUT[MSG,JMC]
FEB75.IN[MSG,JMC]
AUG75.IN[MSG,JMC]
JUL75.IN[MSG,JMC]
XGPPUB.1[ESS,JMC]
ADMIT.PUB[CUR,JMC]
KHABAR.AI[S75,JMC]
NEWS75.SUP[ESS,JMC]
NAKATA.LE1[LET,JMC]
REPRES.DOC[ESS,JMC]
REPRES.NOT[ESS,JMC]
HENDRI.REV[ESS,JMC]
LEM.LE1[LET,JMC]
REPRES.REP[ESS,JMC]
HOMER.LE1[LET,JMC]
SCHULT.LE1[LET,JMC]
TWOEAS.MEM[258,JMC]
OPTIM[F75,JMC]
LUMELS.LE1[LET,JMC]
DYSON.LE1[LET,JMC]
NEWBOR.REV[F75,JMC]
NICK.FIL[F75,JMC]
TASK.TA[F75,JMC]
SEXP[F75,JMC]
LATIME.LE1[LET,JMC]
AI[F75,JMC]
GENERA[F75,JMC]
LISP.MAN[S75,JMC]
SANDEW.LE2[LET,JMC]
DEFINE[F75,JMC]
PHIL.ART[F75,JMC]
BULLET[F75,JMC]
DATA3.204[F75,JMC]
DATA1.204[F75,JMC]
DATA4.204[F75,JMC]
ISHII.LE1[LET,JMC]
EDH.DO[ESS,JMC]
ED1.DO[ESS,JMC]
TEXTOR.LE1[LET,JMC]
OFFICE.PLN[F75,JMC]
REPRES.P75[ 1,JMC]
AIORG.PLN[ 1,JMC]
ASHENH.LE1[LET,JMC]
ASHENH.LE2[LET,JMC]
IJCAI.DOC[F75,JMC]
IJCAI.ENQ[F75,JMC]
LUK.LE1[ 2,JMC]
DCL2.75[LET,JMC]
AAAS[ESS,JMC]
AAAS.76[ESS,JMC]
NILSSO.ME1[LET,JMC]
SCIENC.LE2[LET,JMC]
HOARE.LE1[LET,JMC]
LUCKHA.LE1[LET,JMC]
SCIENC.LE3[LET,JMC]
ABELSO.LE1[LET,JMC]
HJERPP.LE1[LET,JMC]
RELATI.POX[CUR,JMC]
BROWN.LE1[LET,JMC]
MOSES.LE1[LET,JMC]
GILFIL.REV[F75,JMC]
SCOTT.LE1[LET,JMC]
SENSE.AD[LET,JMC]
PR1.DEC[F75,JMC]
AJT.MEM[ESS,JMC]
RAWLS.REV[ESS,JMC]
SENSE.POS[F75,JMC]
CYCLOP[F75,JMC]
GINI.LE1[LET,JMC]
MARTEL.LE1[LET,JMC]
MARTEL.DOC[LET,JMC]
FRIED.LE1[LET,JMC]
ROTH.LE1[LET,JMC]
FRIED.LE2[LET,JMC]
FIXUP.LBK[F75,JMC]
FIX[F75,JMC]
BRINKE.LE1[LET,JMC]
TABLE[F75,JMC]
BLIROB.AX[226,JMC]
TERMPA.206[F75,JMC]
FIXUP2.LBK[F75,JMC]
BLIROB.DOC[226,JMC]
RYLE.REV[F75,JMC]
FIXUP[F75,JMC]
TUNNEY.LE1[LET,JMC]
FIXUP2[F75,JMC]
NEWS75.PUB[CUR,JMC]
BLIROB.COM[226,JMC]
BRINKL.LE1[LET,JMC]
JAF.LE1[LET,JMC]
SENSE.LE1[LET,JMC]
MOTIV.ART[ AI,JMC]
GARDNE.LE2[LET,JMC]
DAILY.ART[F75,JMC]
SENSE.LE2[LET,JMC]
REVAL3.LBK[F75,JMC]
REVAL2.LBK[F75,JMC]
AUTOMA[F75,JMC]
AUTOMA.2[F75,JMC]
COUNTE[F75,JMC]
PR1.AX[F75,JMC]
HOTER.1[CUR,JMC]
MELTZE.LE[LET,JMC]
HOTER[CUR,JMC]
NOV.ME[LET,JMC]
MACHIN[F75,JMC]
HEAD.LET[LET,JMC]
BETHE.LE1[LET,JMC]
SENSE.DAT[F75,JMC]
GOLDMA.LE1[ 2,JMC]
BETHE.LE2[LET,JMC]
FINITI[F75,JMC]
SOULE.LE1[LET,JMC]
SCIENT.LE1[LET,JMC]
MINIMA[F75,JMC]
THESIS[F75,JMC]
FIB[F75,JMC]
DEC75.IN[LET,JMC]
FIELDS.SUP[LET,JMC]
NEWYOR.LE1[LET,JMC]
CHERN.LE1[LET,JMC]
KAHN.LE1[LET,JMC]
RAPHAE.LE1[LET,JMC]
GARDNE.LE1[LET,JMC]
FIELDS.ME1[LET,JMC]
BLEDSO.LE1[LET,JMC]
BLEDSO.DOC[LET,JMC]
YOST.LE1[LET,JMC]
GABOR.LE1[LET,JMC]
RHODES.LE1[LET,JMC]
LISP.INT[F75,JMC]
BLOCKS.226[F75,JMC]
NOTES.226[F75,JMC]
TAUT.PRF[F75,JMC]
UTILI.AIL[F75,JMC]
MOSSIG.LE1[LET,JMC]
PET.LIT[LIT,JMC]
TOLEDO.LE1[LET,JMC]
CBCL[F75,JMC]
SET.AX[F75,JMC]
SET[F75,JMC]
SENSE.LE3[LET,JMC]
FILMAN.RE2[LET,JMC]
CONS.AX[226,JMC]
SMULLY[226,JMC]
GIL1[ 2,JMC]
KNOPOF.LE1[LET,JMC]
YAMADA.LE1[LET,JMC]
CULIK.LE1[LET,JMC]
JAN76.IN[LET,JMC]
MILLER.LE0[LET,JMC]
ANDREI.ADR[ESS,JMC]
LUCKHA.BLA[F75,JMC]
JAN76.OUT[LET,JMC]
ARPA75.IN[MSG,JMC]
ADMIT.TEL[LET,JMC]
LICK.1[LET,JMC]
MENTAL.NOT[F75,JMC]
PHIL.ART[ESS,JMC]
WILSON.LE1[LET,JMC]
WILKIN.LE1[LET,JMC]
BIB.PUB[SEN,JMC]
GERROL.LE1[LET,JMC]
OSIS.LE1[LET,JMC]
SFWA[S76,JMC]
COMPUT.CSD[ESS,JMC]
CSDCOM[ 1,JMC]
CSDDIS.N25[ESS,JMC]
QUOTE.2[SEN,JMC]
BAT0.LOG[F75,JMC]
QUOTE[SEN,JMC]
TECHNI.MEN[F75,JMC]
AUTOMA.MEN[F75,JMC]
MODEL.MEN[F75,JMC]
EPISTE.MEN[F75,JMC]
OBSERV.MEN[F75,JMC]
CELLUL.MEN[F75,JMC]
RELDEF.MEN[F75,JMC]
MOTIV.MEN[F75,JMC]
CONTEN.MEN[F75,JMC]
NOTE.MEN[F75,JMC]
POLEMI.MEN[F75,JMC]
NOTE1.MEN[F75,JMC]
AI.MEN[F75,JMC]
MOTIVA.MEN[F75,JMC]
SELFCO.MEN[F75,JMC]
CHANGE.MEN[F75,JMC]
CRYPT.MEM[ 2,JMC]
CRYPT.CHK[ 2,JMC]
COMMUN[S76,JMC]
SLAGLE.REC[ESS,JMC]
ENERGY.FAC[ESS,JMC]
FELDST.REV[ESS,JMC]
CHARAC.PRO[ESS,JMC]
ED.DO[ESS,JMC]
MAGS.LIS[ESS,JMC]
SCITOP.LIS[ESS,JMC]
ANDREI.DAT[ESS,JMC]
GREET[ESS,JMC]
MUSIC.GRP[ESS,JMC]
EVENT.NOT[ESS,JMC]
GRK.TES[ESS,JMC]
POEM[ESS,JMC]
PSYCHO.AP[ESS,JMC]
TASK.FOO[ESS,JMC]
DICT1[ESS,JMC]
SUSAN.TAX[ESS,JMC]
ALL[ESS,JMC]
IGC.PRO[ESS,JMC]
JO.NO2[ESS,JMC]
RACRUL.MEM[ESS,JMC]
DRAW.PRO[ESS,JMC]
VIEW1[ESS,JMC]
IGSCS.PLN[ESS,JMC]
MINSKY.LE[ESS,JMC]
NEWMEX.SPE[ESS,JMC]
LORE[ESS,JMC]
SPUT.PRO[ESS,JMC]
SUBTES[ESS,JMC]
CSDCOM.REQ[ESS,JMC]
LIST[ESS,JMC]
TECH2.BGL[ESS,JMC]
GUBBB[ESS,JMC]
FREE[ESS,JMC]
COLE.LET[ESS,JMC]
LIGHT.6[ESS,JMC]
BANK[ESS,JMC]
SERA.ZOO[ESS,JMC]
PUBLIC.INT[ESS,JMC]
PRO2[ESS,JMC]
JAN75.DBX[ESS,JMC]
LIVER.SAI[ESS,JMC]
ENERGY.DEM[ESS,JMC]
REGIST[ESS,JMC]
∂07-Jan-78 1409 FTP:Cathy Shaw at MIT-ML Quasar expose.
Date: 7 JAN 1978 1711-EST
From: Cathy Shaw at MIT-ML
Sent-by: BAK at MIT-ML
Subject: Quasar expose.
To: BAK at MIT-ML, BKPH at MIT-ML, MAB at MIT-ML, MTM at MIT-ML
To: jmc at SU-AI, mark.fox at CMU-10A, mhr at MIT-AI, minsky at MIT-AI
To: henry at MIT-AI, dht at MIT-AI
I have spent the last few months gathering material for an article about
Quasar robots. I have interviewed people from around MIT and have also
taken some material from the MINSKY;ROBOT > file. The following people
were quoted from the file: Mark Fox, John McCarthy. The following people
were quoted from direct interview: Marvin Minsky, Bill Kornfeld, Dave
Taenzer, Mark Raibert, Henry Lieberman. A draft of my article is on
AI:DHT;KLATU >, and an XGP'ble version is AI:DHT;KLATU XGP. I would
appreciate comments about inaccuracies in the text. Send all comments to
DHT@MIT-AI. My present intention is to publish this in a national publication
such as the Wall Street Journal. Thanks for all the help you have given
me.
--Cathy Shaw
∂08-Jan-78 0139 FTP:CARL at MIT-AI (Carl Hewitt) just checking
Date: 8 JAN 1978 0440-EST
From: CARL at MIT-AI (Carl Hewitt)
Subject: just checking
To: jmc at SU-AI
CC: CARL at MIT-AI
John,
I just realized that there is another pitfall in using my evaluators in
MACLISP: you might inadvertantly call an fsubr such as "OR", "AND", or "PROG".
I have patched the evaluators given below so that they will give you
a warning message. If you want me to make them work for the above fsubrs, I
will be happy to oblige.
Did you receive my previous two messages which contained the MACLISP
evaluators and a request for a current copy of your paper?
!(defun bind←identifiers (identifiers values environment expression)
(cond ((null identifiers)
(cond ((null values)
environment)
(t (error '|Too Few Arguments| expression))))
((null values)
(error '|Too Many Arguments| expression))
(t (cons (list (car identifiers) (car values))
(bind←identifiers (cdr identifiers)
(cdr values)
environment
expression)))))
(defun lookup (identifier environment)
(cond ((null environment)
(error '|Unbound Variable| identifier))
((equal identifier (caar environment))
(cadar environment))
(t (lookup identifier (cdr environment)))))
(defun bound? (identifier environment)
(cond ((null environment)
nil)
((equal identifier (caar environment))
(cadar environment))
(t (bound? identifier (cdr environment)))))
!
; First define the evaluator which uses dynamic scoping:
(defun dynamic←eval (expression environment)
(cond ((atom expression)
(cond ((or (null expression) (equal expression 't) (numberp expression))
expression)
(t (lookup expression environment))))
((atom (car expression))
(cond ((eq (car expression) 'quote)
(cadr expression))
((eq (car expression) 'lambda)
expression)
((eq (car expression) 'cond)
(dynamic←process←cond←clauses (cdr expression) environment))
((getl (car expression) '(fexpr fsubr))
(error '|Unknown Procedure| expression))
(t (dynamic←apply (car expression)
(dynamic←eval←list (cdr expression) environment)
expression
environment))))
(t (dynamic←apply (dynamic←eval (car expression) environment)
(dynamic←eval←list (cdr expression) environment)
expression
environment))))
(defun dynamic←apply (procedure arguments expression environment)
(cond ((atom procedure)
(cond ((get procedure 'expr)
(dynamic←apply (get procedure 'expr) arguments expression environment))
(t
(apply procedure arguments))))
((eq (car procedure) 'lambda)
(dynamic←eval (caddr procedure)
(bind←identifiers
(cadr procedure)
arguments
environment
expression)))
(t (error '|Unknown Procedure| (list procedure arguments)))))
(defun dynamic←process←cond←clauses (clauses environment)
(cond ((null clauses)
nil)
((dynamic←eval (caar clauses) environment)
(dynamic←eval (cadar clauses) environment))
(t (dynamic←process←cond←clauses (cdr clauses) environment))))
(defun dynamic←eval←list (expressions environment)
(cond ((null expressions)
nil)
(t (cons (dynamic←eval (car expressions) environment)
(dynamic←eval←list (cdr expressions) environment)))))
!
; Now by changing the way that lambda expressions are evaluated
;we obtain an interpreter which uses lexical scoping [like the lambda calculus of Church
;and ALGOL-60]:
(defun lexical←eval (expression environment)
(cond ((atom expression)
(cond ((or (null expression) (equal expression 't) (numberp expression))
expression)
(t (lookup expression environment))))
((atom (car expression))
(cond ((eq (car expression) 'quote)
(cadr expression))
((eq (car expression) 'lambda)
(list 'closure (cdr expression) environment))
((eq (car expression) 'cond)
(lexical←process←cond←clauses (cdr expression) environment))
((bound? (car expression) environment)
(lexical←apply (lookup (car expression) environment)
(lexical←eval←list (cdr expression) environment)
expression))
((getl (car expression) '(fexpr fsubr))
(error '|Unknown Procedure| expression))
(t (lexical←apply (car expression)
(lexical←eval←list (cdr expression) environment)
expression))))
(t (lexical←apply (lexical←eval (car expression) environment)
(lexical←eval←list (cdr expression) environment)
expression))))
(defun lexical←apply (procedure arguments expression)
(cond ((atom procedure)
(cond ((get procedure 'expr)
(lexical←apply (lexical←eval (get procedure 'expr) ())
arguments
expression))
(t
(apply procedure arguments))))
((eq (car procedure) 'closure)
(lexical←eval (cadadr procedure)
(bind←identifiers (caadr procedure)
arguments
(caddr procedure)
expression)))
(t (error '|Unknown Procedure| (list procedure arguments)))))
(defun lexical←process←cond←clauses (clauses environment)
(cond ((null clauses)
nil)
((lexical←eval (caar clauses) environment)
(lexical←eval (cadar clauses) environment))
(t (lexical←process←cond←clauses (cdr clauses) environment))))
(defun lexical←eval←list (expressions environment)
(cond ((null expressions)
nil)
(t (cons (lexical←eval (car expressions) environment)
(lexical←eval←list (cdr expressions) environment)))))
(defun fib (n)
(cond ((zerop n) 1)
((equal n 1) 2)
(t (plus (fib (difference n 1)) (fib (difference n 2))))))
(defun reverse (l)
(cond ((null l)
nil)
(t
(append (reverse (cdr l)) (list (car l))))))
(defun create←pair (x y)
(lambda (m)
(cond ((equal m 'left)
x)
((equal m 'right)
y)
(t (error '|Unknown Message| m)))))
(defun left (l) (l 'left))
(defun right (l) (l 'right))
(lexical←eval '((create←pair 3 4) 'left) ()) ;this wins
(lexical←eval '(left (create←pair 3 4)) ()) ;this wins
(dynamic←eval '((create←pair 3 4) 'left) ()) ;this loses
(dynamic←eval '(left (create←pair 3 4)) ()) ;this loses
∂08-Jan-78 1602 FTP:PRATT at MIT-AI (Vaughan Pratt)
Date: 8 JAN 1978 1854-EST
From: PRATT at MIT-AI (Vaughan Pratt)
To: JMC at SU-AI
Home: (617) 893 4590
Work: (617) 253 5876
Assume working hours of M-F 1000-1830.
∂09-Jan-78 0949 PAT j,pat and ito
Yes, you did send a letter to Ito claiming he had been a student here, also,
thanks for cleaning up j,pat, the bio is your current one.
∂09-Jan-78 1537 TOB student
John
A student, Chris Liu, met with me today. He is at
Purdue with Fu. His interest is in three-dimensional
vision and wants to transfer here. He was admitted
before in EE and is told he can get admission here
provided he has an advisor and support. I looked
over what he knows, his strengths and like what
he has: analysis, math, hardware.
I said yes, contingent on your agreeing and
good references. I will call tomorrow for references
from Lou Paul.
What do you say?
Tom
Sure, if you have the money.
∂09-Jan-78 2219 TOB terminals
John
I want to get a couple more terminals for hand/eye
personnel. Are Datamedia still the best choice?
Tom
Ask Les.
∂10-Jan-78 2251 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR on WEDNESDAYS
**********
PLACE: ERL 237
TIME: 2.30 pm.
RESULTS OF ORGANIZATIONAL MEETING
*********************************
1. TIME CHANGE: To avoid conflict with CS150 the seminars will now be
held on WEDNESDAYS at 2.30pm in ERL 237
2. The first seminar, next Wednesday will be given by Corky Cartwright.
3. Topics to be presented and possible speakers (not in any significant order):
Pratts Dynamic Logic.........Harel or Manna
Subgoal Induction.............King
Modal Logic...................Owicki
Processes: two papers of Gilles Kahn.....Luckham
Guttag's data structures and some extensions....Polak
Concurrent Systems Language.....Karp and Luckham
Euclid.........................?
Send suggestions and volunteers for other topics and speakers to DCL.
4. SYSTEM MEETING: There will be a system meeting after Corky's seminar
to discuss the toplevel commands of the newest verifier. A draft proposal
for this discussion will be circulated by Friday.
∂11-Jan-78 0913 CJS computer chess
There is a computer chess tournament scheduled to run during the computer faire.
They want to know if you know of anyone who would be interested in displaying
their hardware or software for computer chess at the faire. If you know of
anyone you can call Roy Elder or Larry Wagner at (56) 745-2810.
∂11-Jan-78 0922 FTP:Levin at SUMEX-AIM forest baskett
Date: 11 JAN 1978 0923-PST
From: Levin at SUMEX-AIM
Subject: forest baskett
To: mccarthy at SAIL
your message to denny was forwarded to me. Do you want
a note sent to senior faculty members and A&P, forest's
vitae or what exactly did you have in mind?
I don't know if anyone told you, but i'm secretary for the
A&P committee...so feel free to contact me directly...laurie
lll@sail
levin@sumex
-------
Please send a note to senior faculty.
∂11-Jan-78 1426 BS F. Baskett
Papers recommending the extension of the Baskett appointment (and the
extension of his leave) were sent to the Dean's Office in late December.
In view of the recent developments, I would like to suggest that it would
be well to alert Dean Royden so that the papers will not be sent to the
Provost, the Board, etc.
Betty
OK, do it.
∂11-Jan-78 1648 LLL next appointments and promotion meeting
Bob Floyd would like to set up the next A&P meeting. How
does next Thur sound? 11:00 or 1:00?...laurie
At 11 on Tues. and Thurs. I have classes. 1pm on Thurs. is ok.
∂12-Jan-78 0531 HPM New privilege system
To: JMC, LES, JBR
Barf. So now i have to waste time writing a program to mess with the
page map so that I'll be able circumvent the protection to run ralph
to restore files, the net, or whatever. Who's shitheaded idea was all
this?
∂12-Jan-78 1100 JMC*
lisp history to Vera and Hewitt
∂12-Jan-78 1435 JMB colloq.txt
Good idea. I will keep copies in both places until Tuesday
when I can announce the change at the colloquium.
....Jeff
∂13-Jan-78 0130 PMF
To: RWW, JMC, TED
I modified the imlac dm simulator to remove the ascii tty mode.
If you have trouble using the new reload program call me.
∂13-Jan-78 0140 GFF via SRKA HOMEPC.NS[1,GFF] @ SAIL
To: JMC, PBaran at USC-ISI, REM
An interesting artical on home computers and what the future looks like
is contained in the formentioned file by the NEw York Times.
[Geoff]
∂13-Jan-78 0752 BS Meeting re Margaret Jacks Hall
To: JMC, JJK, LES
CC: RWF, BS
Roger Buckhout of the University Planning Office has scheduled a meeting
to discuss the keying and security of MJHall on Tuesday, January 17,
l0:00 a.m., Conference Room A, Old Pavilion. Please note that the Planning
Office is now located in the Old Pavilion. If you do not plan to attend
this meeting, please let me know.
Betty
∂13-Jan-78 1033 DES
John,
I've received two letters from Dimitri Belov, one of the Russians
who participated in the last two IJCAI's, both of which are signed
with what appears to be either "Dima" or "Dimc". If this (or something
which might look like it) is a diminutive for "Dimitri", I'd like
to use it in writing back to him. Do you happen to know? If not,
am I at least spelling Dimitri correctly (that is, in a reasonably
anglicized way)? Thanks for your help,
David
∂13-Jan-78 1646 FTP:Levin at SUMEX-AIM Senior Faculty meeting
Date: 13 JAN 1978 1646-PST
From: Levin at SUMEX-AIM
Subject: Senior Faculty meeting
To: buchanan, lederberg, mccarthy at SAIL
The meeting was originally scheduled for Friday,
January 20th at 4:00. Professor McCluskey as
asked us to begin the meeting at 4:30 on the 20th.
Please let me know if this time is agreeable with you.
Thanks...laurie
levin@sumex
lll@sail
-------
4:30 is ok with me.
∂13-Jan-78 1651 FTP:Lederberg at SUMEX-AIM Re: Senior Faculty meeting
Date: 13 JAN 1978 1650-PST
From: Lederberg at SUMEX-AIM
Subject: Re: Senior Faculty meeting
To: Levin, buchanan, mccarthy at SAIL
In response to the message sent 13 JAN 1978 1646-PST from Levin
I will be out of town 1/20; but proceed regardless
-------
∂13-Jan-78 2159 RWW BLIND ROBOT
IT READ IN PERFECTLY THE FIRST TIME. I CAN'T MAKE THE BUG I
FOUND HAPPEN AGAIN!!!! ARE YOU SURE IT DOESN'T KNOW WHEN YOUR
WATCHING?
RWW
∂14-Jan-78 1143 FTP:Hayes-Roth at Rand-Unix Comments on AI Technology Forecast Outline
Date: 14 Jan 1978 at 1138-PST
Sender: Rick at Rand-Unix
Subject: Comments on AI Technology Forecast Outline
Subject: [Reply to your message of 4 Jan 1978 1103-PST]
From: Hayes-Roth at Rand-Unix
To: Hart at Sri-Kl
cc: Feigenbaum at Sumex-Aim, JMC at Su-Ai, Minsky at Mit-Ai,
cc: Amarel at Rutgers-10, Uncapher at Usc-Isi, Winograd at Su-Ai,
cc: Rick at Rand-Unix, Denicoff at Usc-Isi, Russell at Usc-Isi
Message-ID: <[Rand-Unix]14-Jan-78 11:38:24.Rick>
Peter-
I have both general and specific comments on your
detailed outline on "Artificial Intellience and National
Security--Some Opportunities." Overall, I think you have created
a well organized and reasonable tour of the future that visits a
few points that seem reachable. On the other hand, the paper
does not really provide a road map of the future, laying out
somewhat fully the alternative courses that AI R&D could run.
Ideally, the paper would develop such a road map and, in
addition, it would provide guidance on how alternatives should be
evaluated. From this perspective, the proposed paper suffers
from two apparent weaknesses: (1) It fails to convey adequately a
sense of the desirable directions that DoD should consider
pursuing and developing; two of the key ingredients needed to
apprehend these choices are missing, namely an assessment of the
AI technology and an assessment of DoD functions for whose
realization AI appears to be the most cost-effective vehicle.
(2) The model of information processing proposed in section II,
while more or less suitable for discussing one class of
activities, is inadequate for framing numerous other types of DoD
functions. As a result, it suggests that most of the potential
applications may not be included. I will elaborate my comments
on these two high-level notions before detailing some of my more
specific suggestions on your proposed outline.
1. Relating AI technology to DoD needs
My basic premise is that the only satisfactory way to approach
the problem of relating AI technology to DoD needs is, first, to
attempt to characterize both and then, by informal methods
(combining Gestalt psychology, means-ends analysis, futurism and
cost-benefit analysis), identify those targets (system
developments) that are most promising. I suppose you have already
done some of this, but the outline suggests that the primary
approach used has been data-driven: the artifacts of the
technology (its projects and systems) are collated, their basic
characteristics are then summarized, and these are projected
forward in time and instantiated by possible new projects. A
more powerful technique it seems would be to characterize
carefully the attributes of the technology (the characteristics
of the problems that make them amenable to its treatments and the
gross performance parameters of such technology), to characterize
several important DoD functions, and then to identify those
functions that are both approachable and exceptional
opportunities. I'm not sure how this can be accomplished
effectively in the paper, since it increases the breadth of
things considered, but at this point it seems like the most
important thing for me is to explain "what" to do, even if I
don't fully explain "how" to do it.
Paraphrasing what was said above, the major issues that the paper should
address are:
1. The AI technology
(Note: a pithy expression of the point of this section would be:
a & b define what the "power" of AI is, c defines the
constraints that enable it to work well)
a. What are its unique characteristics?
b. What is its scope?
c. What are its performance characteristics?
i. How is it turned into products?
ii. What characterizes the types of products that
it is advantageous for (as opposed to those for which
it is relevant but impractical or expensive vis-a-vis
alternative technologies)?
2. The DoD information processing functions
a. What are they?
b. How can they be characterized in ways that allow the
comparisons of their characteristics with those of the
technology?
3. Mapping the two together to select ideal targets of opportunity
a. Things that are recognized as very important
(either for economic reasons or military effectiveness
reasons)
b. Things that only AI can do (or that AI can do better
and cheaper than alternatives, but this second type
of class of things is harder to identify)
c. Are there revolutionary possibilities for DoD that
AI suggests?
i. What kinds of changes would they be?
ii. What is their economic value?
iii. What kind of probability of success would
we experts assign to a research program aimed
at them?
My overall impression is that your proposed original outline
touches on some of these themes but in oblique ways. I have
discussed my ideas, as suggested in the above outline, with
several other people, and all have agreed that it provides a more
direct and focused consideration of the important issues than
your outline conveyed. If you find those basic ideas attractive,
the following more detailed outline should be of value to you.
It's my attempt to refine the gross issues in the outline above.
What the following list is strong on is comprehensiveness and
relevance. What it is still weak on is the identification,
communication and emphasis of the few most significant and unique
characteristics of the technology vis-a-vis the DoD problems
whose discussion would follow.
CHARACTERISTICS OF AI TECHNOLOGY
Elements of the technology
Symbolic information manipulated
Data representations (those unique to AI)
Relationship representations (e.g., facts, cause-effect
models)
Method representations (tactics, procedures, heuristics)
Functional concepts
Situation description (e.g., pattern template, precondition)
Inference generation
Algorithmic
Heuristic
Hypotheses and decisions (outputs of inference generators)
Alternatives, arising from:
Data uncertainties
Knowledge uncertainties (relationships or methods)
Attempts to foresee consequences of possible actions
Inherent ambiguity of problem domains
Choice
Evaluation (desirability, promise, certainty)
Pruning
Search
Combinatorics
System development
Problem formulation
Knowledge formulation (data, relations, methods written down)
Hardware selection
Software development
Design
Engineering
Implementation
Testing
Methodology of application
Two dimensions of task complexity
Environmental variability and complexity circumscribed
Competence and sophistication of system behavior
Successive expansions of objectives on both dimensions
Transfer of successful previous methodologies
Attempts to mimic human reasoning processes
Necessitates advice taking from problem expert
Divide-and-conquer large problems
Create high-level man-machine cooperations that
exploit relative advantages of each
Sources of technological advance
Demand-driven research (mission-oriented research)
Focus upon specific capabilities rather than general
mechanisms
Successive expansions of objectives on 2 task dimensions
Capability to acquire and represent relevant knowledge
=> Tasks solvable with limited knowledge are
preferable as starting points than are
tasks requiring extensive amounts of knowledge
=> Ideal tasks increase in complexity in a way that
can be resolved with linear increases in knowledge
Availability of liberal research computing resources
(e.g., INTERLISP cycles)
Sustained team efforts
Isolation of AI system development from exogenous
information processing tasks (e.g., data collection)
Effective constraints on applicability and technological advance
Even moderately general intellectual skills are too broad
=> Problem domains must be limited in breadth
=> They can't be realized by general, syntactic
methods
Problems that humans can solve and can explain how are best
Software development is a critical bottleneck
Hardware design is not limiting AI applications at this time
Verification of heuristic program logic is likely to be
impossible
=> Humans cannot be taken out of loop of critical
decisions in general systems
Performance parameters
Need to estimate amount of knowledge in various programs
and assess their development costs (man-years)
Point is that most of the cost in system development is
spent in software engineering, just like in other
systems
Only logically simple searches are currently doable in or
near real-time
Many interesting tasks may not be doable until new
problem representations, algorithms and hardware
are discovered unless they are greatly constrained
and simplified (e.g., image analysis)
Characterization of problems amenable to the technology
A complex version varies from a simple version of the problem
primarily in the amount of knowledge required,
which should increase linearly with complexity,
and the amount of computing cycles needed,
which should increase not much faster than linearly
with complexity
Strong suggestions or theories exist about how people do the
task or these can be extracted directly from experts
at moderate cost--machine implementations of weak
methods are likely to produce limited results
Complex problems should be divisible into smaller subproblems
that require only limited subsets of knowledge
CHARACTERIZATION OF DOD FUNCTIONS
(This is illustrative, even exemplary, but surely not exhaustive)
ASSESSMENT FUNCTIONS
Technological forecasting
Political forecasting
Economic forecasting
Military scenario forecasting
Surveillance
Intelligence
Multi-source integration and interpretation (fusion)
PLANNING FUNCTIONS
Policy forecasting
Forecasting political objectives, alliance relationships,
military options
Formulating information needs
Obtaining and communicating crisis related information
Goal formulation
Action-plan generation
Target selection
Route selection
Resource allocation
Scheduling
Logistics
Action-plan evaluation
Formulating and insuring readiness (some potential areas for AI)
Manpower
Training
Administrative services
Arms
Targeting capabilities
Signature identifcation
Terrain following
Multi-source sensor integration
ECM
Support
Command, control and communication system
Mobilization
CONTROL FUNCTIONS
Communication of plans to units
Monitoring of intermediate outcomes of plans
Feedback control of deviating units
Revision of plans that are failing
Filtering of information for detecting exceptions and alerting
TROUBLESHOOTING FUNCTIONS
Characterization of the malfunction
Hypothesization of cause
Formulation of experimental test of hypothesis
Interpretation of test results
Maintenance scheduling
Inventory maintenance
Surely this list is incomplete in many ways, but it suggests that
DoD functions can largely be viewed as information processing
problems: assessing information about current or future
situations, developing and evaluating plans for responses to
present or potential dangers, collecting information about how
the plans are being executed and generating new control
information to errant units, and collecting information from
malfunctioning vehicles or platforms to diagnose their failures.
The heavy investment in these decision making tasks suggests that
AI may be widely applicable.
TARGETS OF OPPORTUNITY FOR AI
Many of the functions that have been discussed above satisfy the
previously developed criteria for potentially successful
applications of AI. For example, inventory maintenance and
resource allocation would seem to be ideal targets of
opportunity: these functions are important, not currently
performed well and are readily defined by heuristics that experts
can generate. Natural language communication, if restricted to
military terminology and scenarios, would also seem amenable to
AI technology. On the other hand, the use of AI systems for
automatically understanding unrestricted natural language (for
example, to read newspapers and write intelligence reports) would
seem to be beyond the capacity of systems developed in the next
20 years. Finally, I will suggest in the next section the
functions that are not likely opportunities for AI (such as
forecasting) embody subfunctions that are generally applicable
and that may be tractable to our methods.
2. Models of Information Processing Functions
Given the 3 main objectives that my proposed alternative outline
covered, the use of models of information processing functions
(as in your section II), seems unnecessary and tangential. The
proposed alternative scheme organizes the paper about the unique
characteristics of AI technology and corresponding DoD functions
that are likely targets of opportunity. It is reasonable to
attempt to communicate the general characteristics of the
information processing problems that underlie the DoD functions
(as your model attempts), but I strongly suspect that such a
model will be ineffective in the context of this paper. As an
abstraction, its effectiveness will be produced by two
countervailing forces it unleashes: since it is general, it
allows you to speak to a large class of instances at one time in
few words; conversely, since it is general, it suggests that it
is disconnected from the real problems and may be a smokescreen
concealing lack of relevance, materiality and merit. I strongly
encourage you to drop the use of the general organizing schema
for these reasons. If you feel you know your audience well
enough that your expectations should be different from mine, then
I would propose specific alternatives to the model you developed.
My suggestions are explained below.
I have already indicated that the analyze -> plan -> act ->
monitor -> analyze model you employed is both good, as far as it
goes, and too limited to stand alone. As you may gather, I would
suggest replacing it by the SITUATION ASSESSMENT, PLANNING,
CONTROL, TROUBLESHOOTING paradigm used in the previous section.
The differences here are not large however: my preference is
based mainly on the more conventional character of the words I
use and their general interpretations. If we consider this
4-tuple as a model of ACTION, I might represent it this way:
ACTION MODEL: SITUATION ASSESSMENT, PLANNING, CONTROL, TROUBLESHOOTING
But it seems clear that there are lots of other paradigmatic
information processing functions that either support these functions
or serve independent objectives. Some of these are represented below:
KNOWLEDGE ACQUISITION: TUNING, ADVICE TAKING, INDUCTION, SIMPLIFICATION,
REORGANIZATION (for computational efficiency)
(INDUCTION: OBSERVATION, HYPOTHESIS FORMATION, EXPERIMENTATION)
COMMUNICATION: INTENTION, MODELING THE RECIPIENT, SIMPLIFICATION, EXPRESSION,
ELABORATION, INTERPRETATION
(INTERPRETATION: SIGNAL PROCESSING, SEGMENTATION, KNOWLEDGE-BASED
HYPOTHESIZATION AND EVALUATION)
PRODUCT DEVELOPMENT: REQUIREMENTS GENERATION, DESIGN, ENGINEERING,
PRODUCTION, TESTING
(Special case: programming--NOTE EXPLOSION OF PROGRAMMING TASKS in DoD)
(Special case: manufacturing)
By considering this additional set of functions, it is possible
to draw a very rough trajectory from the current state to targets
of opportunity through various subfunctions. Each of these is
more or less amenable to AI technology given the characteristics
previously suggested. For example, if the target were "the
ability for a commander to express a natural language sentence or
two to the machine characterizing a desired battle plan and to
have the machine translate that into a completely detailed order
of battle and communications to field commanders," the number of
intermediate research objectives would be very large and a
considerable number of them would not satisfy the primary
research criterion of being successively expandable in their two
dimensions. On the other hand, a number of important
subfunctions can be identified that are ideal targets of
opportunity, such as automatic programming which addresses a
low-level support function that costs the military plenty because
of the number of times the problem is instantiated. The fact
that most projections of military needs include vastly expanded
(in the two dimensions) C3 capabilities suggests that a key
bottleneck that may be amenable only to AI is software
development. I see this particular one as a 20-year objective.
Given this expanded set of functions or information processing
paradigms, we can ask how well your outline communicates the
potential impact of AI. I think your choice of examples fails to
communicate the unique opportunities and capabilities derived
from AI. You should ask for each one: Would a bright scientist,
who is ignorant of AI's distinctive characteristics, feel that
your examples are uniquely possible through AI? Lots of non-AI
people and techniques are around for resource allocation decision
making, feedback control of systems, restricted language parsing,
monitoring sensors, alerting functions, controlling weapons, etc.
You must do a much better job conveying the special and new
capabilities. Avoid at all cost proposing examples that
engineers think they can do. That suggests choosing examples
that are either very high-level functions, require signal
processing to be integrated with symbolic reasoning, or special
purpose heuristic and synthetic reasoning systems (not simple
allocation decisions or comparable problems that can be conceived
of in decision-analytic frameworks).
It seems to me that the entire paper should be developed to
project a coherent picture of the future possibilities and that
it should be organized from the start to build upon early
examples and discussion toward a few carefully selected
suggestions of target opportunities. I think the original
outline does that pretty well, through the vehicle of your
information processing cycle model; on the other hand, since the
model is too narrow and the targets of opportunity not carefully
chosen, it might be better to scrap what is there (sections II-
IV) and replace it with discussions of about one significant
opportunity in each type of paradigm. After that is done, you
should be in a position to generate a long list of examples of
opportunities in each paradigm, although for these no claim of
desirability (good problem characteristics, high significance,
non-existent or expensive alternatives) needs to be made since
their role is to provide a comprehensive scope to the document
(breadth as opposed to depth). As it currently stands, there is
not enough latent interest in or depth of analysis of any single
example presented that would capture your reader's attention and
imagination and thereby enable you to sell the big ideas while
simply trying to communicate them.
3. Other shortcomings of the proposed paper -- a grab-bag of comments
What are some of the truly revolutionary potentials of AI for the military?
I must have missed it, if you said it. Here are some candidates:
Centralized C2 with distributed control (where have all
the chains of command gone?). AI is probably the
only viable vehicle for coupling together
remotely piloted vehicles and other precision
guided munitions with the reconnaissance and
decision making systems (abetted by viable
communications). Once these other technologies
are ready (quite soon), DoD will probably want to
consider centralizing decision making at the
highest levels possible. The new technologies
will then make possible the elimination of the
functional reason for the chain of command
concept.
Machine-based institutional memories: why do we have to
start over every time personnel changes happen?
The idea is to undertake a major "Heuristic
programming project" across high-level DoD job
roles to record decision makers' knowledge. The
problem of recording, retrieving and using their
knowledge is apparently feasible over the next 20
years.
Weapon invention: One candidate application which, by
practically any cost-benefit evaluation scheme I
can think of, looks to be an outstanding target of
opportunity, would be an AI heuristic design
program that would attempt to invent new weapons
concepts and help in their design and evaluation.
The methodology would be to represent the
concepts and functional relationships in
carefully selected technology areas, collect a
large set of heuristics on what kinds of new
concepts and relationships would be interesting
conjectures from previous ones, and then
proceed in a manner like AM. The reason I
feel this idea is worth mentioning explicitly is
that it's unique in several ways. The actual
payoff of even 1 radically different weapon is
vast (multibillions). The possibility of success
is non-negligible. The cost is small enough to
make this risk very attractive to DoD planners.
War theory: Anyone familiar with the comprehensive war
fighting models that underlie DoD strategic and
tactical planning should realize that the
simulations are a primitive but more or less
essential technology for the evaluation of
possible war fighting strategies. However, they
are used in very restricted ways and, to my
knowledge, don't contribute at a fast enough pace
to the development of theory of war. From this
point of view, such a theory is an empirical
objective that could be greatly facilitated by AI
assistants and assistance. Further, real-time war
theorist assistants could provide the guts of
on-board battle management machines on bombers or
C3 centers such as AWACS successors.
Semi-autonomous decision and control systems:
Surveillance, reconaissance and attack functions
can be expressed in understandable terms
(programming heuristics), converted into
integrated stand-alone systems in widely
disparate contexts.
Forecasting: Forecasting, I previously suggested, is
probably not doable over the next 20 years at a
level of success that would achieve status as
"accurate predictor" or "seer." On the other
hand, the problem is important enough and
uniquely accessible to AI that it is possible to
see a good target of opportunity here. Suppose
we decide that to be valuable as a forecaster, we
need to be able to achieve at least probability P
that one of our N predictions will be realized.
(P might be .3-.99 for different problems, and N
might range from 1 to several hundred). We could
probably achieve this capability in some
interesting domains. A ramification of this
capability would be the ready perception that
contingency plans should be robust over the large
categories evident in the N alternatives, rather
than being specifically developed, one by one,
for each of the varying alternatives. This would
radically alter the view of tactical and
strategic planning and would be a healthy AI-
induced improvement in understanding these
important functions.
What are some of the technology breakthroughs that might change the course
of AI? Here are some:
Memory technology:
Multidimensional semiconductor memories: Why? Because the
ability to store and retrieve information in ways
that are topologically homomorphic to environments
of interest may be very important.
List processing memories, especially for associative retrieval
...
Automatic programming, English programming, or programming assistants
Large-scale integrated multiprocessor circuits, for cooperative
problem solving algorithms
If AI is "artificial intelligence" and people have "natural
intelligence," can you suggest organizations of symbiotic problem
solving systems that would help point out where the biggest need
for AI is (by where the people are unavailable or inadequate)?
One specific question arises from your frequent use of "planning"
where the word "scheduling" is more appropriate. "Planning"
means to me a lot more than it does to the people who have so far
tried to approach it in AI "scheduling" problem solvers.
In general, the dissatisfaction you and I both sense with the
conclusions section reflects its wekaness and generality. I
think the conclusions would better be a summary of the cost-
benefit desirabilities of several significant targets of
opportunity. They would carry the force of planning imperatives.
Thus, I think this section ought not to add to what goes before
it, and therefore should not be outlined in advance. If you wish
specific inputs on your individual items, however, here are some.
Conclusion A-1--I'm not sure what you're about to say, but I'm
pretty sure I disagree. That is, I don't see combinatorics as
the major problem. They're usually a symptom of weak methods or
impossible problems that have solvable, acceptable substitutes.
A-3--Don't raise this flag as a worry for AI. It's hackneyed,
and already implicit in lots of other technologies (e.g., fire
control, feedback control, etc.). I think you're asking for
unnecessary trouble here. Part B--If this said, "The national
resource of AI is limited, the number of significant efforts that
can be promoted is small, the best are X, Y and Z, and we must
organize ourselves to pursue them," I would understand and agree.
* * * * * * * * * * * * * * * * * * * * *
I hope this will be of value to you. Let me know
how it affects your thinking.
- Rick
∂14-Jan-78 1149 FTP:Hayes-Roth at Rand-Unix Comments on AI Technology Forecast Outline
Date: 14 Jan 1978 at 1144-PST
Sender: Rick at Rand-Unix
Subject: Comments on AI Technology Forecast Outline
Subject: [Reply to your message of 4 Jan 1978 1103-PST]
From: Hayes-Roth at Rand-Unix
To: Hart at Sri-Kl
cc: Feigenbaum at Sumex-Aim, JMC at Su-Ai, Minsky at Mit-Ai,
cc: Amarel at Rutgers-10, Uncapher at Usc-Isi, Winograd at Su-Ai,
cc: Rick at Rand-Unix, Denicoff at Usc-Isi, Russell at Usc-Isi
Message-ID: <[Rand-Unix]14-Jan-78 11:44:19.Rick>
Peter-
I have both general and specific comments on your
detailed outline on "Artificial Intellience and National
Security--Some Opportunities." Overall, I think you have created
a well organized and reasonable tour of the future that visits a
few points that seem reachable. On the other hand, the paper
does not really provide a road map of the future, laying out
somewhat fully the alternative courses that AI R&D could run.
Ideally, the paper would develop such a road map and, in
addition, it would provide guidance on how alternatives should be
evaluated. From this perspective, the proposed paper suffers
from two apparent weaknesses: (1) It fails to convey adequately a
sense of the desirable directions that DoD should consider
pursuing and developing; two of the key ingredients needed to
apprehend these choices are missing, namely an assessment of the
AI technology and an assessment of DoD functions for whose
realization AI appears to be the most cost-effective vehicle.
(2) The model of information processing proposed in section II,
while more or less suitable for discussing one class of
activities, is inadequate for framing numerous other types of DoD
functions. As a result, it suggests that most of the potential
applications may not be included. I will elaborate my comments
on these two high-level notions before detailing some of my more
specific suggestions on your proposed outline.
1. Relating AI technology to DoD needs
My basic premise is that the only satisfactory way to approach
the problem of relating AI technology to DoD needs is, first, to
attempt to characterize both and then, by informal methods
(combining Gestalt psychology, means-ends analysis, futurism and
cost-benefit analysis), identify those targets (system
developments) that are most promising. I suppose you have already
done some of this, but the outline suggests that the primary
approach used has been data-driven: the artifacts of the
technology (its projects and systems) are collated, their basic
characteristics are then summarized, and these are projected
forward in time and instantiated by possible new projects. A
more powerful technique it seems would be to characterize
carefully the attributes of the technology (the characteristics
of the problems that make them amenable to its treatments and the
gross performance parameters of such technology), to characterize
several important DoD functions, and then to identify those
functions that are both approachable and exceptional
opportunities. I'm not sure how this can be accomplished
effectively in the paper, since it increases the breadth of
things considered, but at this point it seems like the most
important thing for me is to explain "what" to do, even if I
don't fully explain "how" to do it.
Paraphrasing what was said above, the major issues that the paper should
address are:
1. The AI technology
(Note: a pithy expression of the point of this section would be:
a & b define what the "power" of AI is, c defines the
constraints that enable it to work well)
a. What are its unique characteristics?
b. What is its scope?
c. What are its performance characteristics?
i. How is it turned into products?
ii. What characterizes the types of products that
it is advantageous for (as opposed to those for which
it is relevant but impractical or expensive vis-a-vis
alternative technologies)?
2. The DoD information processing functions
a. What are they?
b. How can they be characterized in ways that allow the
comparisons of their characteristics with those of the
technology?
3. Mapping the two together to select ideal targets of opportunity
a. Things that are recognized as very important
(either for economic reasons or military effectiveness
reasons)
b. Things that only AI can do (or that AI can do better
and cheaper than alternatives, but this second type
of class of things is harder to identify)
c. Are there revolutionary possibilities for DoD that
AI suggests?
i. What kinds of changes would they be?
ii. What is their economic value?
iii. What kind of probability of success would
we experts assign to a research program aimed
at them?
My overall impression is that your proposed original outline
touches on some of these themes but in oblique ways. I have
discussed my ideas, as suggested in the above outline, with
several other people, and all have agreed that it provides a more
direct and focused consideration of the important issues than
your outline conveyed. If you find those basic ideas attractive,
the following more detailed outline should be of value to you.
It's my attempt to refine the gross issues in the outline above.
What the following list is strong on is comprehensiveness and
relevance. What it is still weak on is the identification,
communication and emphasis of the few most significant and unique
characteristics of the technology vis-a-vis the DoD problems
whose discussion would follow.
CHARACTERISTICS OF AI TECHNOLOGY
Elements of the technology
Symbolic information manipulated
Data representations (those unique to AI)
Relationship representations (e.g., facts, cause-effect
models)
Method representations (tactics, procedures, heuristics)
Functional concepts
Situation description (e.g., pattern template, precondition)
Inference generation
Algorithmic
Heuristic
Hypotheses and decisions (outputs of inference generators)
Alternatives, arising from:
Data uncertainties
Knowledge uncertainties (relationships or methods)
Attempts to foresee consequences of possible actions
Inherent ambiguity of problem domains
Choice
Evaluation (desirability, promise, certainty)
Pruning
Search
Combinatorics
System development
Problem formulation
Knowledge formulation (data, relations, methods written down)
Hardware selection
Software development
Design
Engineering
Implementation
Testing
Methodology of application
Two dimensions of task complexity
Environmental variability and complexity circumscribed
Competence and sophistication of system behavior
Successive expansions of objectives on both dimensions
Transfer of successful previous methodologies
Attempts to mimic human reasoning processes
Necessitates advice taking from problem expert
Divide-and-conquer large problems
Create high-level man-machine cooperations that
exploit relative advantages of each
Sources of technological advance
Demand-driven research (mission-oriented research)
Focus upon specific capabilities rather than general
mechanisms
Successive expansions of objectives on 2 task dimensions
Capability to acquire and represent relevant knowledge
=> Tasks solvable with limited knowledge are
preferable as starting points than are
tasks requiring extensive amounts of knowledge
=> Ideal tasks increase in complexity in a way that
can be resolved with linear increases in knowledge
Availability of liberal research computing resources
(e.g., INTERLISP cycles)
Sustained team efforts
Isolation of AI system development from exogenous
information processing tasks (e.g., data collection)
Effective constraints on applicability and technological advance
Even moderately general intellectual skills are too broad
=> Problem domains must be limited in breadth
=> They can't be realized by general, syntactic
methods
Problems that humans can solve and can explain how are best
Software development is a critical bottleneck
Hardware design is not limiting AI applications at this time
Verification of heuristic program logic is likely to be
impossible
=> Humans cannot be taken out of loop of critical
decisions in general systems
Performance parameters
Need to estimate amount of knowledge in various programs
and assess their development costs (man-years)
Point is that most of the cost in system development is
spent in software engineering, just like in other
systems
Only logically simple searches are currently doable in or
near real-time
Many interesting tasks may not be doable until new
problem representations, algorithms and hardware
are discovered unless they are greatly constrained
and simplified (e.g., image analysis)
Characterization of problems amenable to the technology
A complex version varies from a simple version of the problem
primarily in the amount of knowledge required,
which should increase linearly with complexity,
and the amount of computing cycles needed,
which should increase not much faster than linearly
with complexity
Strong suggestions or theories exist about how people do the
task or these can be extracted directly from experts
at moderate cost--machine implementations of weak
methods are likely to produce limited results
Complex problems should be divisible into smaller subproblems
that require only limited subsets of knowledge
CHARACTERIZATION OF DOD FUNCTIONS
(This is illustrative, even exemplary, but surely not exhaustive)
ASSESSMENT FUNCTIONS
Technological forecasting
Political forecasting
Economic forecasting
Military scenario forecasting
Surveillance
Intelligence
Multi-source integration and interpretation (fusion)
PLANNING FUNCTIONS
Policy forecasting
Forecasting political objectives, alliance relationships,
military options
Formulating information needs
Obtaining and communicating crisis related information
Goal formulation
Action-plan generation
Target selection
Route selection
Resource allocation
Scheduling
Logistics
Action-plan evaluation
Formulating and insuring readiness (some potential areas for AI)
Manpower
Training
Administrative services
Arms
Targeting capabilities
Signature identifcation
Terrain following
Multi-source sensor integration
ECM
Support
Command, control and communication system
Mobilization
CONTROL FUNCTIONS
Communication of plans to units
Monitoring of intermediate outcomes of plans
Feedback control of deviating units
Revision of plans that are failing
Filtering of information for detecting exceptions and alerting
TROUBLESHOOTING FUNCTIONS
Characterization of the malfunction
Hypothesization of cause
Formulation of experimental test of hypothesis
Interpretation of test results
Maintenance scheduling
Inventory maintenance
Surely this list is incomplete in many ways, but it suggests that
DoD functions can largely be viewed as information processing
problems: assessing information about current or future
situations, developing and evaluating plans for responses to
present or potential dangers, collecting information about how
the plans are being executed and generating new control
information to errant units, and collecting information from
malfunctioning vehicles or platforms to diagnose their failures.
The heavy investment in these decision making tasks suggests that
AI may be widely applicable.
TARGETS OF OPPORTUNITY FOR AI
Many of the functions that have been discussed above satisfy the
previously developed criteria for potentially successful
applications of AI. For example, inventory maintenance and
resource allocation would seem to be ideal targets of
opportunity: these functions are important, not currently
performed well and are readily defined by heuristics that experts
can generate. Natural language communication, if restricted to
military terminology and scenarios, would also seem amenable to
AI technology. On the other hand, the use of AI systems for
automatically understanding unrestricted natural language (for
example, to read newspapers and write intelligence reports) would
seem to be beyond the capacity of systems developed in the next
20 years. Finally, I will suggest in the next section the
functions that are not likely opportunities for AI (such as
forecasting) embody subfunctions that are generally applicable
and that may be tractable to our methods.
2. Models of Information Processing Functions
Given the 3 main objectives that my proposed alternative outline
covered, the use of models of information processing functions
(as in your section II), seems unnecessary and tangential. The
proposed alternative scheme organizes the paper about the unique
characteristics of AI technology and corresponding DoD functions
that are likely targets of opportunity. It is reasonable to
attempt to communicate the general characteristics of the
information processing problems that underlie the DoD functions
(as your model attempts), but I strongly suspect that such a
model will be ineffective in the context of this paper. As an
abstraction, its effectiveness will be produced by two
countervailing forces it unleashes: since it is general, it
allows you to speak to a large class of instances at one time in
few words; conversely, since it is general, it suggests that it
is disconnected from the real problems and may be a smokescreen
concealing lack of relevance, materiality and merit. I strongly
encourage you to drop the use of the general organizing schema
for these reasons. If you feel you know your audience well
enough that your expectations should be different from mine, then
I would propose specific alternatives to the model you developed.
My suggestions are explained below.
I have already indicated that the analyze -> plan -> act ->
monitor -> analyze model you employed is both good, as far as it
goes, and too limited to stand alone. As you may gather, I would
suggest replacing it by the SITUATION ASSESSMENT, PLANNING,
CONTROL, TROUBLESHOOTING paradigm used in the previous section.
The differences here are not large however: my preference is
based mainly on the more conventional character of the words I
use and their general interpretations. If we consider this
4-tuple as a model of ACTION, I might represent it this way:
ACTION MODEL: SITUATION ASSESSMENT, PLANNING, CONTROL, TROUBLESHOOTING
But it seems clear that there are lots of other paradigmatic
information processing functions that either support these functions
or serve independent objectives. Some of these are represented below:
KNOWLEDGE ACQUISITION: TUNING, ADVICE TAKING, INDUCTION, SIMPLIFICATION,
REORGANIZATION (for computational efficiency)
(INDUCTION: OBSERVATION, HYPOTHESIS FORMATION, EXPERIMENTATION)
COMMUNICATION: INTENTION, MODELING THE RECIPIENT, SIMPLIFICATION, EXPRESSION,
ELABORATION, INTERPRETATION
(INTERPRETATION: SIGNAL PROCESSING, SEGMENTATION, KNOWLEDGE-BASED
HYPOTHESIZATION AND EVALUATION)
PRODUCT DEVELOPMENT: REQUIREMENTS GENERATION, DESIGN, ENGINEERING,
PRODUCTION, TESTING
(Special case: programming--NOTE EXPLOSION OF PROGRAMMING TASKS in DoD)
(Special case: manufacturing)
By considering this additional set of functions, it is possible
to draw a very rough trajectory from the current state to targets
of opportunity through various subfunctions. Each of these is
more or less amenable to AI technology given the characteristics
previously suggested. For example, if the target were "the
ability for a commander to express a natural language sentence or
two to the machine characterizing a desired battle plan and to
have the machine translate that into a completely detailed order
of battle and communications to field commanders," the number of
intermediate research objectives would be very large and a
considerable number of them would not satisfy the primary
research criterion of being successively expandable in their two
dimensions. On the other hand, a number of important
subfunctions can be identified that are ideal targets of
opportunity, such as automatic programming which addresses a
low-level support function that costs the military plenty because
of the number of times the problem is instantiated. The fact
that most projections of military needs include vastly expanded
(in the two dimensions) C3 capabilities suggests that a key
bottleneck that may be amenable only to AI is software
development. I see this particular one as a 20-year objective.
Given this expanded set of functions or information processing
paradigms, we can ask how well your outline communicates the
potential impact of AI. I think your choice of examples fails to
communicate the unique opportunities and capabilities derived
from AI. You should ask for each one: Would a bright scientist,
who is ignorant of AI's distinctive characteristics, feel that
your examples are uniquely possible through AI? Lots of non-AI
people and techniques are around for resource allocation decision
making, feedback control of systems, restricted language parsing,
monitoring sensors, alerting functions, controlling weapons, etc.
You must do a much better job conveying the special and new
capabilities. Avoid at all cost proposing examples that
engineers think they can do. That suggests choosing examples
that are either very high-level functions, require signal
processing to be integrated with symbolic reasoning, or special
purpose heuristic and synthetic reasoning systems (not simple
allocation decisions or comparable problems that can be conceived
of in decision-analytic frameworks).
It seems to me that the entire paper should be developed to
project a coherent picture of the future possibilities and that
it should be organized from the start to build upon early
examples and discussion toward a few carefully selected
suggestions of target opportunities. I think the original
outline does that pretty well, through the vehicle of your
information processing cycle model; on the other hand, since the
model is too narrow and the targets of opportunity not carefully
chosen, it might be better to scrap what is there (sections II-
IV) and replace it with discussions of about one significant
opportunity in each type of paradigm. After that is done, you
should be in a position to generate a long list of examples of
opportunities in each paradigm, although for these no claim of
desirability (good problem characteristics, high significance,
non-existent or expensive alternatives) needs to be made since
their role is to provide a comprehensive scope to the document
(breadth as opposed to depth). As it currently stands, there is
not enough latent interest in or depth of analysis of any single
example presented that would capture your reader's attention and
imagination and thereby enable you to sell the big ideas while
simply trying to communicate them.
3. Other shortcomings of the proposed paper -- a grab-bag of comments
What are some of the truly revolutionary potentials of AI for the military?
I must have missed it, if you said it. Here are some candidates:
Centralized C2 with distributed control (where have all
the chains of command gone?). AI is probably the
only viable vehicle for coupling together
remotely piloted vehicles and other precision
guided munitions with the reconnaissance and
decision making systems (abetted by viable
communications). Once these other technologies
are ready (quite soon), DoD will probably want to
consider centralizing decision making at the
highest levels possible. The new technologies
will then make possible the elimination of the
functional reason for the chain of command
concept.
Machine-based institutional memories: why do we have to
start over every time personnel changes happen?
The idea is to undertake a major "Heuristic
programming project" across high-level DoD job
roles to record decision makers' knowledge. The
problem of recording, retrieving and using their
knowledge is apparently feasible over the next 20
years.
Weapon invention: One candidate application which, by
practically any cost-benefit evaluation scheme I
can think of, looks to be an outstanding target of
opportunity, would be an AI heuristic design
program that would attempt to invent new weapons
concepts and help in their design and evaluation.
The methodology would be to represent the
concepts and functional relationships in
carefully selected technology areas, collect a
large set of heuristics on what kinds of new
concepts and relationships would be interesting
conjectures from previous ones, and then
proceed in a manner like AM. The reason I
feel this idea is worth mentioning explicitly is
that it's unique in several ways. The actual
payoff of even 1 radically different weapon is
vast (multibillions). The possibility of success
is non-negligible. The cost is small enough to
make this risk very attractive to DoD planners.
War theory: Anyone familiar with the comprehensive war
fighting models that underlie DoD strategic and
tactical planning should realize that the
simulations are a primitive but more or less
essential technology for the evaluation of
possible war fighting strategies. However, they
are used in very restricted ways and, to my
knowledge, don't contribute at a fast enough pace
to the development of theory of war. From this
point of view, such a theory is an empirical
objective that could be greatly facilitated by AI
assistants and assistance. Further, real-time war
theorist assistants could provide the guts of
on-board battle management machines on bombers or
C3 centers such as AWACS successors.
Semi-autonomous decision and control systems:
Surveillance, reconaissance and attack functions
can be expressed in understandable terms
(programming heuristics), converted into
integrated stand-alone systems in widely
disparate contexts.
Forecasting: Forecasting, I previously suggested, is
probably not doable over the next 20 years at a
level of success that would achieve status as
"accurate predictor" or "seer." On the other
hand, the problem is important enough and
uniquely accessible to AI that it is possible to
see a good target of opportunity here. Suppose
we decide that to be valuable as a forecaster, we
need to be able to achieve at least probability P
that one of our N predictions will be realized.
(P might be .3-.99 for different problems, and N
might range from 1 to several hundred). We could
probably achieve this capability in some
interesting domains. A ramification of this
capability would be the ready perception that
contingency plans should be robust over the large
categories evident in the N alternatives, rather
than being specifically developed, one by one,
for each of the varying alternatives. This would
radically alter the view of tactical and
strategic planning and would be a healthy AI-
induced improvement in understanding these
important functions.
What are some of the technology breakthroughs that might change the course
of AI? Here are some:
Memory technology:
Multidimensional semiconductor memories: Why? Because the
ability to store and retrieve information in ways
that are topologically homomorphic to environments
of interest may be very important.
List processing memories, especially for associative retrieval
...
Automatic programming, English programming, or programming assistants
Large-scale integrated multiprocessor circuits, for cooperative
problem solving algorithms
If AI is "artificial intelligence" and people have "natural
intelligence," can you suggest organizations of symbiotic problem
solving systems that would help point out where the biggest need
for AI is (by where the people are unavailable or inadequate)?
One specific question arises from your frequent use of "planning"
where the word "scheduling" is more appropriate. "Planning"
means to me a lot more than it does to the people who have so far
tried to approach it in AI "scheduling" problem solvers.
In general, the dissatisfaction you and I both sense with the
conclusions section reflects its wekaness and generality. I
think the conclusions would better be a summary of the cost-
benefit desirabilities of several significant targets of
opportunity. They would carry the force of planning imperatives.
Thus, I think this section ought not to add to what goes before
it, and therefore should not be outlined in advance. If you wish
specific inputs on your individual items, however, here are some.
Conclusion A-1--I'm not sure what you're about to say, but I'm
pretty sure I disagree. That is, I don't see combinatorics as
the major problem. They're usually a symptom of weak methods or
impossible problems that have solvable, acceptable substitutes.
A-3--Don't raise this flag as a worry for AI. It's hackneyed,
and already implicit in lots of other technologies (e.g., fire
control, feedback control, etc.). I think you're asking for
unnecessary trouble here. Part B--If this said, "The national
resource of AI is limited, the number of significant efforts that
can be promoted is small, the best are X, Y and Z, and we must
organize ourselves to pursue them," I would understand and agree.
* * * * * * * * * * * * * * * * * * * * *
I hope this will be of value to you. Let me know
how it affects your thinking.
- Rick
∂14-Jan-78 1236 RSC
I finally found a termination proof for NORMALIZE with a simpler induction
than the one Boyer and Moore use, but I'm still not entirely happy with it.
In addition, I discovered a simpler version of Boyer and Moore's proof.
Let W_DEPTH be defined by:
W_DEPTH[E] ← CASE E OF
ATOM: 1
IF[A,B,C]: 2*W_DEPTH[A] + MAX[W_DEPTH[B],W_DEPTH[C]]
The termination of NORMALIZE[E] proceeds by ordinary structural induction
on W_DEPTH[E]; no double induction is necessary.
The only non-trivial subgoal generated in the proof is
W_DEPTH[IF[A,IF[B,D,E],IF[C,D,E]]] < W_DEPTH[IF[IF[A,B,C],D,E]]
which reduces to:
2*A' + 2*MAX[B',C'] + MAX[D',E'] < 4*A' + 2*MAX[B',C'] + MAX[D',E']
where A',B',C',D',E' denote W_DEPTH[A],W_DEPTH[B],W_DEPTH[C],W_DEPTH[D],
W_DEPTH[E], respectively.
The simpler version of Boyer and Moore's proof uses the following
definition of IF_COMPLEXITY instead of Boyer and Moore's:
IF_COMPLEXITY[E] ← CASE E OF
ATOM: 1
IF[A,B,C]: IF_COMPLEXITY[A] +
MAX[IF_COMPLEXITY[B],IF_COMPLEXITY[C]].
The proof is essentially unchanged.
∂14-Jan-78 2105 DCL
To: GROUP.DIS[VCG,DCL]:;
***********************************************************************
VERIFICATION GROUP SEMINAR WEDNESDAY 18th. JANUARY
PLACE: ERL 237
TIME: 2:30 pm.
TITLE: "Unrestricted Procedure Calls in Hoare's Logic"
SPEAKER: CORKY CARTWRIGHT
This is a topic about which there is some controversy. The Euclid people
have attempted to generalize Hoares procedure call rule too, and we will
probably be told of their errors. Corky is presenting this talk at POPL.
There will be a verifier system meeting 3.30 - 4.15.
*******************************************************************
∂15-Jan-78 1701 SJT via RNDU
You are mentioned in an article on the quasar `robot' which appeared in
last Wednesday's Christian Science Monitor.
∂15-Jan-78 2241 JMC
8am blood
∂15-Jan-78 2314 FTP:CARL at MIT-AI (Carl Hewitt) just checking
Date: 16 JAN 1978 0215-EST
From: CARL at MIT-AI (Carl Hewitt)
Subject: just checking
To: jmc at SU-AI
CC: CARL at MIT-AI
John,
What do you think of the MACLISP interpreters? Do they meet your
needs. Could you please send me a hard copy of the current version of your
paper.
Thanks,
Carl
I haven't looked again but will soon. I think I sent the paper but will
check.
∂15-Jan-78 2340 MRC via WPAT PETITION
To: JMC, LES
PETITION
I object to the new privilege scheme on principle. It has created a class
of omnipotent users (ie, JBR, ME, and BH) over and above all others. I
also object to the screws which this has introduced and while the god
squad may be fixing them, they are nonetheless an annoyance.
This new system has seriously diminished SAIL in my viewpoint as a
pleasant and open place to work. I am asking that administrative decisions
be made to reverse this trend before it becomes even more intolerable.
∂16-Jan-78 0918 PAT
∂15-Jan-78 2324 JMC
Did I send Carl Hewitt the LISP history paper in the last week?
[yes - patte]
∂16-Jan-78 0933 FTP:Levin at SUMEX-AIM letter to Mrs. Forsythe re: contribution to dept.
Date: 16 JAN 1978 0933-PST
From: Levin at SUMEX-AIM
Subject: letter to Mrs. Forsythe re: contribution to dept.
To: mccarthy at SAIL
Thought I'd bug you about letter to Mrs. Forsythe...do you want
to send her a form letter?...laurie
-------
No. Please try to write one on the basis of preceding such letters,
and I'll try to improve it or else start over.
∂16-Jan-78 1156 DCO seminar
To: SSO, JMC
The AI colloquium is this thursday at 4 pm; at 3:30 there is a DSL
colloquium. I have to attend the former (because it is by one of our students
presenting our joint POPL paper) and so cannot attend Donahue's talk. I
suspect that there are various people who wish to hear both the AI colloquium
and Donahue, in particular all the people in the verification group.
Is it too late to plan one to precede the other?
∂16-Jan-78 1202 FTP:Levin at SUMEX-AIM letter to Mrs. Forsythe
Date: 16 JAN 1978 1118-PST
From: Levin at SUMEX-AIM
Subject: letter to Mrs. Forsythe
To: jmc at SAIL
We wish to express our appreciation for your recent gift to
the Computer Science Department.
Gifts are greatly appreciated, not only because the
Department needs money, but also because it expresses a vote
of confidence. Gifts are often designated for a specific
purpose, such as the Computer Science Library, the Forsythe
Memorial Award, and the Forsythe Memorial Lectureship. The
General Gift Fund will assist in the new building program
which is aimed toward consolidating the Department into one
building, the Margaret Jacks Hall in the Quad.
The needs are great and your continuing support is very
important. We are grateful for your interest in the
Computer Science Department.
Cordially,
/lsl
-------
∂16-Jan-78 1207 FTP:Levin at SUMEX-AIM letter to Mrs. Forsythe
Date: 16 JAN 1978 1120-PST
From: Levin at SUMEX-AIM
Subject: letter to Mrs. Forsythe
To: mccarthy at SAIL
We wish to express our appreciation for your recent gift to
the Computer Science Department.
Gifts are greatly appreciated, not only because the
Department needs money, but also because it expresses a vote
of confidence. Gifts are often designated for a specific
purpose, such as the Computer Science Library, the Forsythe
Memorial Award, and the Forsythe Memorial Lectureship. The
General Gift Fund will assist in the new building program
which is aimed toward consolidating the Department into one
building, the Margaret Jacks Hall in the Quad.
The needs are great and your continuing support is very
important. We are grateful for your interest in the
Computer Science Department.
Cordially,
/lsl
Well that won't do. I meant previous letters to Mrs. Forsythe
who is my personal friend as well as the personal friend of
Ed Feigenbaum and Bob Floyd. I'll come in tomorrow and see
what I can figure out.
∂16-Jan-78 1220 MRC
To: LES, JMC
∂16-Jan-78 1217 RPG Privileges
I guess I basically agree with your sentiments, but
not quite as strongly.
Now that there isn't a crew of (trustworthy) people with
privileges around to help out at odd hours, more official responsibility
must be given to the privileged. For instance, JBR, ME, and BH should be
subject to phone calls at all hours regarding such trivial things as
"what's my password", "fix the imp",and etc.
A second thing is: why do the people who do have the privilieges have
them. BH is not a systems person right now. He "works" for LLL and
since there is no S1 project per se, he is equivalent to a guest.
When JBR and ME switch to S1 from system, I doubt they should have
the privileges since they are then USERs.
The old system had the ombudsman approach wherein average
users could take their occaisionally silly requests to a local godfather
who understood their problems well (unlike JBR and ME who denigrate unfortunates
unless they are in the intelligentsia and thus only ask "important" things).
My main concern is not that there is a upper class, but that the upper
class acts like a traditional one and that the issue seems to have been overblown
in officialdon only: LES was the only person to think this was a real issue,
and the Systems people jumped on the technicalities of implementation. 3-4
man-weeks were spent on the implementation which could have been better spent.
-rpg-
∂16-Jan-78 1220 MRC via WPAT privileges
To: RPG
CC: JMC, LES
Your points are well taken. I must admit some guilt for what happened;
I pressured for things to be changed, but my pressure totally backfired.
I wanted privileges as something available to the "god squad" only to
be flushed, and the bits used more for confirmation purposes.
I agree; JBR and ME should now be available for phone calling at all
hours (ha! someday YOU try reaching JBR late at night!!!). I don't
understand the logic of BH being part of the god squad either. Note
that Les and JMC were excluded too!
Your point about JBR and ME going to S1 and becoming USERs is damn
good! I wonder what their reaction will be to that! I doubt it would
happen, but they should know the outrage that we have felt.